Product
Billing Ledger
Subscriptions, invoices, payments and a double-recorded ledger in exact minor units, where a payment settles only against a real provider reference.
On this page
What it does
The Billing Ledger records what an account owes and what it has paid. Amounts are whole minor units in a stated currency; no figure is held as a floating-point number.
What exists now
| Capability | What it does | Where |
|---|---|---|
| Subscriptions | An account sees its own subscriptions. A renewal run issues invoices and stamps a due date from the subscription's payment terms. | Billing |
| Invoices and payments | An account sees its invoices and the payments allocated to them. | Ledger |
| Recording a payment | A staff step records a payment received against an issued invoice. It is created pending; the amount cannot exceed what is still unallocated, and the invoice row is locked so two recordings cannot over-allocate it. | POST /econ/payments, staff |
| Settlement | A pending payment settles only with a real provider reference and a reconciliation stamp; the database refuses a settlement without both. | POST /econ/reconcile, operator |
| Ledger | Journal entries are append-only; balances are derived from them and the runtime role cannot write a balance directly. | Ledger |
Data handling
Billing records are tied to the account and are visible to that account only. The privacy notice states retention.
Operating needs
- PostgreSQL with the platform's migrations applied by the schema owner.
- A person with staff authority to record payments and run reconciliation, because there is no payment gateway.
Limits
- No card or gateway integration exists: payments are recorded from a transfer RJV confirms, and the platform does not move money.
- No tax calculation is built in.
- Settlement is never inferred; an unreconciled payment stays pending.
Availability
The Billing Ledger is running on RJV's own platform. RJV does not sell a licence for it as a separate product today: the commercial terms state what is on sale. It can be part of the result of an engineering engagement, where the written proposal names it, its licence terms and what you would hold at the end. To discuss it, use Work with Us.
Evidence
The invariants above are enforced by database constraints and exercised by the platform's own tests, including posting a journal entry as the production runtime role. The evidence register lists the graded claims.
Works with
- Identity and Access: Requires. Invoices and subscriptions belong to an account.
- Audit Chain: Works with. Ledger postings and settlements are recorded in the chain.
Where it runs
| Supported target | A customer-controlled Linux host on x86-64 with PostgreSQL 18 (linux-x86_64-customer-controlled). |
|---|---|
| Not yet supported | Windows, macOS, phones and tablets, and Linux on other architectures. Each needs its own installation, update and recovery evidence before it is supported. |
| Check a device | Run rjv2 preflight on it. It reads the operating system, architecture, memory, disk, listen address, configuration, database, database role and schema, changes nothing, and exits non-zero if release 2.0.0-alpha.1 cannot run there. |
| Installed as | One application and a PostgreSQL database. Installing release 2.0.0-alpha.1 (schema 100) installs every system on this site, including Billing Ledger. |
| Data | It stays in the PostgreSQL database you run. The only outside service the release can use is an outbound mail relay that you configure. |
| Updating | A release is a numbered build. The schema is applied by a separate owner step (rjv2 migrate), and the application refuses to serve a schema it was not built for. |
| Backup and restore | rjv2 backup writes a checksummed dump. rjv2 restore restores it into an empty database and checks the checksum, the schema version and the audit chain of every account. |
| Leaving | The data is in your own database and can be dumped at any time. What you may do with the release is set by the terms on deployment and ownership. |
- Published
- 29 October 2026
- Revision
- 1