Controls that live below the app.
Most software promises correctness in the application layer — the layer every bug goes through. Cenco enforces its rules where the data lives, so the books can't drift even if everything above them misbehaves.
Not checked after. Rejected at write.
An unbalanced entry cannot be written. A posted entry cannot be silently changed. A closed period cannot quietly accept a backdated posting. These aren't policies your team must remember — they're constraints the system physically enforces, and they're re-verified continuously.
INVARIANT sum(debits) = sum(credits) · every posting
INVARIANT posted entries are immutable · append-only
INVARIANT closed periods stay closed · reopening is a named event
Attacked before it ships
Adversarial review
Every security-sensitive change is reviewed from multiple independent, adversarial angles before it lands — and the findings get fixed, not filed.
Continuous re-proof
The foundational claims — global balance, no floats in money paths, subledgers tying to their controls — are re-verified automatically after every change.
Attacks become tests
When an adversarial pass finds a way to bend the books, that attack is added to the permanent test suite. The same failure can never ship twice.
SOC 2 · evidence collection underway; certification is a roadmap item, not a badge we wear early
bank feeds at scale · statement import is live; live aggregator feeds are coming
autonomous AI accounting · never — drafts require human posting, structurally
Ask us how the invariants are enforced. Then ask your current vendor the same question.
Apply →