Your books stay yours, and every change is on the record.
This page is written for the person doing diligence — often an accountant on a client's behalf. Every claim on it is one our engineers would sign: it describes what the system enforces today, states provider-inherited properties as provider properties, and ends with a plain list of the things we don't claim yet.
Enforced, then tested on every change
Isolation isn't a design intention here — it's a test suite. On every change to the codebase, an automated suite runs against a real Postgres database: it creates two businesses and asserts, in both directions and for every tenant-scoped table, that neither can read the other's rows. A companion check fails the build if anyone adds a table holding tenant data without an isolation policy. The audit log's immutability and the ledger's balance rules are tested the same way — by attempting the forbidden operation and asserting the database refuses.
Who can get in
Sign-in runs on Supabase Auth: email and password, Google, and — in the iOS app, which isn't publicly released yet — Sign in with Apple. Sessions are verified server-side against the auth service, not just decoded from a cookie. Inside a business, four roles (Owner, Bookkeeper, Employee, External Accountant) are checked against a single authorization matrix — there's no screen where a role quietly means something different. Sign-in, sign-up, password, and upload endpoints are rate-limited, and uploaded files are validated by content, not by their claimed type.
For our own staff to work inside your account, the business Owner has to consent explicitly, in the app. That access is read-only unless write access is separately confirmed, it expires after sixty minutes, and every step of it lands in your own audit log — request, consent, start, and end.
Multi-factor authentication is not yet available. It's on the list below, not dressed up here.
Retention, export, and deletion
Our retention policy for receipts is seven years, matching standard recordkeeping expectations. Today nothing deletes receipts at all — there is no automated expiry — so the practical posture is stronger than the policy floor: what you put in stays until you ask us to remove it.
Getting data out: every report exports as CSV or PDF, and tax export packages are plain CSVs built for handoff. A single full export of an entire business — ledger, files, and audit log in one archive — is not built yet. Deleting a user account anonymizes personal details while leaving the books' audit trail intact, because accounting records that reference people have to survive the people leaving; deleting an entire business, and anything else this section doesn't cover, is handled directly — write to security@numm.io and a person deals with it.
Backup and recovery posture
Database backups are managed by Supabase, our database provider. What we have not yet done is run our own restore drill and publish recovery-time and recovery-point objectives — that work is on the pre-launch hardening list, and this page will state the results when the drill has actually been performed, not before.
Encryption follows the same rule: connections run over TLS and data at rest is encrypted by Vercel, Supabase, and AWS. Those are properties of the platforms we build on — real, but inherited — and we state them as such rather than presenting them as our own engineering.
Who else touches your data
The subprocessors Nummio relies on, and what each one actually receives.
| Subprocessor | Purpose |
|---|---|
| Supabase | Database (Postgres), authentication, and file storage |
| Vercel | Web application hosting |
| Amazon Web Services | Receipt text extraction, and temporary storage for large receipts during that process |
| Anthropic | AI categorization and field cleanup on receipt data |
| Stripe | Three separate roles: your invoice payments, your Nummio subscription billing, and — if you connect a bank — read-only bank transaction and balance data via Financial Connections. Nummio never sees or stores your bank credentials. |
| Postmark | Inbound receipt email and outbound notifications |
| Inngest | Background job processing for receipts, invoices, and other async workflows |
| Sentry | Error reports from the application, with stack traces and request context |
| Plausible | Visitor analytics on this marketing site only — a test enforces it never loads inside the signed-in product |
| Sign-in with Google, for accounts that choose it | |
| Apple | Sign in with Apple and push notifications, once the iOS app releases |
One near-miss worth naming: daily currency rates come from openexchangerates.org, but that's an inbound fetch — no tenant data goes to them, so they aren't a subprocessor.
What we don't claim yet
A diligence page that only lists strengths isn't a diligence page. As of today: there is no SOC 2 attestation (work toward one is on the list), no multi-factor authentication, no self-serve full-business export, and no published, drill-verified recovery objectives. If any of these is a hard requirement for you today, we'd rather you know now — and if it's a conversation, we're easy to reach.
Doing diligence for a client?
Ask the specific question — security@numm.io reaches people who can answer with specifics, not a form response.