← All projects

Service metering · Backend and data systems

Usage reconciliation ledger

A usage ledger with exact decimal quantities, corrections, and monthly closes. Late events stay separate from closed reports until an operator posts an adjustment.

Local service and operations rehearsal completed

Synthetic February usage reconciliation, including late usage and a correction.
Synthetic February usage reconciliation, including late usage and a correction.

Implementation

Account-scoped source events have an idempotent identity and exact integer base units. A correction appends a reversal and replacement; original input remains unchanged.

Closing reconciles entries with the total cache, records ingest and posting cutoffs, and freezes a versioned export. Late events and corrections to closed periods wait for an operator to post them into a later open period.

The operator console exposes ingestion, correction review, closing, reconciliation and downloads. SQLite write transactions serialize ingest and close so either the new usage is included or it is recorded as pending.

Checked online SQLite snapshots, restore into a new directory, and a periodic backup command are included. An executed operations rehearsal covers abrupt process exits, recovery and rejected inputs.

Inputs and assumptions

  • The January/February 2026 example is synthetic. Calendar periods use UTC.
  • Units are API calls, compute minutes and storage GiB-hours. Fractional units allow three decimal places; API calls are integral. No pricing or invoicing is included.
  • Python 3.12 and local SQLite replace the earlier PostgreSQL deployment plan. Account-period writes are serialized through SQLite's single writer.

Results

Recorded results for the included reference case
Integration tests passed24
January compute usage19.750 minutes
January API calls1,250
February compute usage after adjustments9.375 minutes
Frozen exports rebuilt and verified2
Operational checks passed19 / 19
Report figures (2)
Local ledger after closing January and posting a late adjustment to February. Synthetic demonstration data.
Local ledger after closing January and posting a late adjustment to February. Synthetic demonstration data.
The recorded February close combines 8.250 current minutes, 3.125 late minutes and a -2.000-minute correction, totaling 9.375 minutes.
The recorded February close combines 8.250 current minutes, 3.125 late minutes and a -2.000-minute correction, totaling 9.375 minutes.

Open the full report ↗

Verification

24 tests pass, including duplicate ingestion, exact arithmetic, correction chains, both ingest/close lock orders, immutable exports, cache corruption detection, account isolation and role checks. A separate operations rehearsal passes 19 expected-outcome checks, including process crashes, checked snapshots, restore and a finite backup schedule.

python verify.py
python demo.py
python operations_rehearsal.py
Download the verification record ↓

Additional scenarios

19 outcomes checked through executed synthetic operations. The report lists the expected and observed outcomes for each check.

Read the validation report ↗

Project files

The ZIP contains the source, inputs, results, and instructions. These files are also available individually.

Download project ZIP · 147 KB
Archive checksum

SHA-256

8193aa9d652d0ed1e4977f3caf557084d871a39cc54b90c5528f1c53382ea7c0
Original project scopeArchived brief PDF ↗

Run locally

Python 3.12+ / SQLite via Python standard library

Extract the ZIP and open a terminal in the usage-reconciliation folder. The README includes setup and usage details.

python app.py --demo
# Open http://127.0.0.1:9090
python verify.py
python demo.py
python build_report.py
python operations_rehearsal.py

Limits

  • Localhost-only application with example bearer tokens. Production identity, TLS termination and distributed coordination are not included.
  • Closed periods cannot be reopened or restated. Adjustments carry forward under the documented rule; changing that accounting policy needs a new implementation and tests.
  • Database triggers prevent ordinary updates to history, but the database owner can change files or schema. This is not a tamper-proof external audit system.
  • No monetary prices, tax, invoices, payments, event-stream connector or production capacity claim.
  • Checked snapshot/restore and a periodic snapshot runner are included. Restoring an older snapshot still requires a separately retained source journal to recover post-snapshot records; the executed replay drill uses synthetic inputs.