Money stays exact
Amounts use exact decimal representation, with each currency’s supported precision enforced by the data model rather than left to display formatting.
decimal · minor-unit constraintThe correctness model
Ledger invariants, enforced by construction.
A polished interface can make a number look trustworthy. Nivium goes beneath presentation and puts each accounting invariant at the strongest practical enforcement point.
The guarantee follows the mechanism.
Nivium does not begin with a marketing promise and search for a test that appears to support it. It begins with the invariant, chooses the strongest layer that can enforce it, then makes the interface communicate what that layer actually knows.
Postings balance before they exist
At transaction commit, the database refuses a posting unless debit and credit totals tie in both functional and presentation currency.
deferred database constraintHistory is corrected, never overwritten
Posted economic history is append-only. A correction creates an attributable reversing event linked to the record it corrects.
narrow grants · exact stornoTenants remain isolated
Forced row-level security binds the application to the active tenant, while narrow database privileges constrain what each runtime may change.
FORCE RLS · least privilegeClose retains its proof
Hard close runs the versioned invariant sweep and stores the rule manifest, schema version, actor, reason, time, and ledger cutoff with the transition.
atomic close attestationA refusal is a feature
When a ledger-critical transition cannot prove it is allowed, it does not write.
Invalid currency precision, missing dimensions, an unbalanced posting, a closed period, a stale revision, or a broken close invariant becomes a named refusal—not a quiet inconsistency waiting to be found downstream.
| Invariant | Enforcement | Result |
|---|---|---|
| posting_balances | database / commit | exact · 0.00 |
| event_posts_in_every_active_book | close sweep / 1.2.0 | complete |
| receivables_control_equals_open_invoices | close sweep / 1.2.0 | clear |
| completed_bank_reconciliations_remain_current | close sweep / 1.2.0 | current |
Put each rule where it can hold.
Types
Closed domain values and exhaustive transitions keep invalid variants from flowing into ledger rules.
Database constraints
Cross-row facts such as balanced postings are checked at commit, where every write path must satisfy them.
Privileges & isolation
The application cannot update or delete posted ledger history, and forced row-level security applies even when a query forgets the boundary.
Guarded writes
Lifecycle transitions carry revisions, actor identity, capabilities, exact source arcs, and explicit idempotency where repetition must be safe.
Laws & mutation
Property tests exercise accounting laws across generated inputs; load-bearing assertions are deliberately broken to prove the gate notices.
Real-path verification
Database contracts, HTTP scenarios, and ledger-critical real-browser accounting journeys finish with an invariant sweep against migrated PostgreSQL.
A mistake should leave an honest history.
Nivium uses exact reversing entries rather than editing the past. The original event remains legible, the correction is a new attributable event, and the pair nets to zero by the same rule structure that created the posting. Reports reflect the result without erasing how the system arrived there.
Correctness, made operational
Bring stronger evidence to the close.
If your finance team needs stronger evidence for why ledger-critical transitions were admitted, we would like to hear how you work.