Veyra

• 01

  One place money moves

  A single posting module owns every balance change — post, replace, void. No feature writes a balance directly, so there is one code path to reason about rather than twenty.

• 02

  Balances are derived, not stored

  An account balance is a cached projection of its ledger entries. If the two ever disagree, the ledger wins and the projection is rebuilt.

• 03

  Append-only history

  Events are voided or replaced, never deleted — so a correction leaves the original and the reason behind it intact rather than quietly rewriting the past.

• 04

  Idempotent posting

  Every posting carries a scope, a key and a hash of its own content. Importing the same statement twice produces the same ledger, not double the money.

• 05

  Statement import

  A PDF or CSV bank statement is parsed into staged rows for review, with duplicates detected and existing entries matched before anything is posted.

• 06

  Dated reconciliation

  Proves an account against a statement at a given date: compares the statement’s closing balance with the ledger-derived balance for that day, explains the gap, and posts an adjustment only on explicit confirmation.

• 07

  Budgets that do not post

  Spending caps are a planning surface, deliberately kept out of the ledger — a budget is an intention, not a transaction, and conflating the two is how forecasts end up in balances.

• 08

  Bills, income and schedules

  Recurring obligations and expected income modelled as schedules, so the question "what is likely to happen next" has something to answer from.

• 09

  Goals, loans and net worth

  Longer-horizon surfaces, with net worth captured as dated snapshots rather than recomputed history — so a past figure stays what it was at the time.

• 10

  Natural-language quick add

  A typed sentence parsed into a draft entry, reviewed before it posts rather than written straight through.

• 11

  Assistant over your own data

  A chat surface answering questions against the ledger, scoped to the signed-in account.

• 12

  Authentication on every procedure

  Clerk-backed sessions, with all 119 real API procedures requiring an authenticated caller — the only public one is the unused base definition. Every query filters on the owning user, and the client never supplies a trusted owner id.

• 13

  Rate limiting at the edge

  Per-user limits on the expensive paths, so a single account cannot exhaust the shared resources behind them.

Approved direction — billing not yet built

• Subscriptions on Stripe

  Customer and subscription objects, checkout, the customer portal, and webhook ingestion — with plan state derived from Stripe’s webhooks rather than trusted from the client.

• Entitlements as their own tables

  Subscription and billing-event tables separate from the finance schema, so a plan change is never confused with a movement of the user’s own money.

• Per-user tenancy, deliberately

  One subscription per user, matching the isolation already enforced in every query. Shared household workspaces were considered and explicitly ruled out of scope rather than left vague.

• The audit came first

  The security and authorisation review was completed before any of the commercial work started — which is what makes the rest of the track additive.