Live reports
derived, never reconciled
P&L, balance sheet, and trial balance are views over the same rows the engine wrote — no sync step, no end-of-day batch.
Architecture
How Paprel is built
The architecture your security and platform reviewers will ask about, stated plainly: how a request becomes a ledger entry, how tenants stay isolated, what the webhook contract guarantees, and how the system deploys. None of it is aspirational — this is the structure running in production today.
From API call to balanced books
Every write — direct journal, invoice, payment, agent tool call — passes the same gates, in the same order. Nothing reaches the ledger unverified.
Your platform
REST · SDK · MCP
One surface, three ways in. The same primitives whether the caller is your backend, a typed SDK, or an AI agent over Model Context Protocol.
Auth & scope
OAuth 2.0 · tenant-scoped
Every token is scoped to a company with per-route grants. The same model powers dashboards, machine clients, and MCP agents.
Idempotency check
seen before? → original result
Retried requests return the original result instead of posting twice. Timeouts and double-clicks cannot double-pay an invoice.
Balance validation
debits = credits, or rejected
Checked at write time, before anything reaches the ledger. There is no code path that lets an unbalanced entry through.
Append-only ledger
corrections are new entries
Posted lines are never edited in place. Versioned documents keep a stable anchor while the full history stays walkable.
Signed webhooks
at-least-once · verifiable
Events carry signatures and content hashes so consumers can verify payload integrity and dedupe redeliveries.
The layered core
Four layers, one set of guarantees
Workflows never bypass the ledger; reports never drift from it. Each layer either compiles into the layer below or derives from it — which is why there is no reconciliation step anywhere in the stack.
Read the full layer-by-layer articleReporting layer
Derived live from journal rows
Reports are views over the ledger, not a second datastore that gets synced and reconciled. The trial balance ties to zero by arithmetic, not by health check.
Workflow layer
Documents compile into journals
Invoices, bills, credit notes, and expenses generate balanced journals through account mappings set once. A compiler into the ledger's guarantees — never a bypass.
Ledger engine
Append-only · balanced or rejected
Journals are the only primitive. If a number appears in a report, there is a journal line behind it — balance-validated at the API boundary.
Tenancy
Isolation enforced at the data layer
A company is the tenant boundary, the set of books, and the reporting entity. Every read and write is scoped below application code — a missing WHERE clause cannot leak tenants.
A company is the boundary
One API call provisions a customer with isolated books of their own — ledger, document numbering, and a default chart of accounts included.
Your platform
one tenant per customer · OAuth-scoped tokens
Customer A
region: US
- Own ledger & chart of accounts
- Isolated at the data layer
- Own audit history
Customer B
region: EU
- Own ledger & chart of accounts
- Isolated at the data layer
- Own audit history
Customer C
region: APAC
- Own ledger & chart of accounts
- Isolated at the data layer
- Own audit history
Isolation is enforced below application code — every read and write is scoped to the company at the data layer, so a missing WHERE clause cannot leak one tenant's journals into another's report.
Safe to retry, built to verify
Every financial API eventually receives the same request twice. In a ledger, a duplicate write isn't a duplicate row — it's an audit problem. So the write path assumes retries.
Retries are the normal case
Timeouts, webhook redeliveries, queue replays — the write path is designed to be retried, because it will be. Idempotency keys deduplicate; resubmitting a journal returns the original result.
Signed, verifiable delivery
Webhooks are delivered at-least-once with signatures and content hashes, so a consumer can verify integrity and safely ignore duplicates.
Recovery without redelivery machinery
Lost events? The ledger is the source of truth — consumers recover from the GL export instead of depending on fragile replay infrastructure.
Audit history, exportable
Changes, approvals, and automation activity land in a signed audit log — retained for seven years and exportable as CSV/JSON.
Three ways to run it
The ledger core and its guarantees are identical across all three — the models exist for distribution and compliance shapes, not as upgrades.
Managed
Paprel hosts, you integrate
- Tenant-pinned regions: US, EU, or APAC — pinned at provisioning, no cross-region replication
- Sandbox is self-serve; production starts at published pricing
- Sandbox and production are separate, isolated environments
The right starting point for almost everyone.
White-label
Paprel powers, your brand fronts
- Every tenant carries your partner attribution — your customer relationship, end to end
- Headless API under your brand — your UI and domain, Paprel underneath
- Same managed infrastructure and guarantees underneath
For platforms that own the accounting experience.
Private / BYOC
Your cloud, scoped together
- Deployment in your infrastructure or on dedicated infrastructure
- Scoped per engagement — conversation first
- The ledger core and its guarantees stay identical
For compliance shapes managed can't express.
Go deeper
The long-form versions
This page is the map. Each area has a full engineering write-up in the documentation — the same documents we point security reviewers at during evaluation.
See the security & trust postureTenancy, isolation, and the ledger core
Company-per-tenant isolation, the append-only engine, and reports derived from the same rows.
Read the articleWebhooks, idempotency, and reliable writes
Why retries are assumed, how the write path stays safe under them, and the signed webhook contract.
Read the articleDeployment models: managed, white-label, private
What each model actually is, when it's the right call, and what never changes between them.
Read the articleArchitecture review
Bring your hardest questions
Talk directly to the engineers who built and operate the ledger — deployment fit, OAuth and MCP scope, data residency, and rollout, in a working session.