Canonical events
Invoices, bills, payments, jobs, time, contracts, bank activity, and documents enter with stable source identity—not uncontrolled journal lines.
Platform / accounting system architecture
We built the hard accounting layer behind your product.
Invarent turns product events into balanced books, subledger state, reconciliations, statements, and accountable workflows while keeping the financial rules out of your application code.
Invarent's financial control plane is the governed layer inside the embedded accounting system. It receives business events, applies policy and authority checks, creates financial effects, and preserves the evidence required to reconcile and report them.
Illustrative control recordIVR / 00381 Reconciled
Control chain
- 01Source receivedinvoice.approved / v1
SRC - 02Policy resolvedAP-US-014 / effective
POL - 03Authority provendistinct actor / bound hash
APR - 04Effect postedbalanced / atomic commit
PST - 05Reconciledsource / ledger / external
REC
Posting effectUSD
- 6100 · Materials expense
- 4,820.00
- 2000 · Accounts payable
- (4,820.00)
- Net financial effect
- 0.00
Content digest
9fb3:0d17:86e4:2c1aExact source retainedSource → policy → authority → posting → reconciliationExample data / not a customer record
The invariant chain
Six control records. One explainable outcome.
Versioned policy
Effective-dated rules determine accounts, dimensions, evidence, materiality, approvals, and exception behavior without changing historical results.
Bounded authority
Tenant identity, scopes, actor separation, professional capacity, expiry, and content hashes constrain consequential actions.
Atomic financial effect
Idempotency, business validation, balanced posting, audit evidence, usage state, and response persistence commit together or not at all.
Independent reconciliation
Source conservation, subledger-to-ledger, and ledger-to-external comparisons remain separate controls with separate evidence.
Immutable reporting
Reports retain tenant, entity, book, basis, currency, period, dimensions, policy version, generation time, and content digest.
System boundary
The user interface presents commands. It does not become the ledger.
- 01
Operating systems remain authoritative for operations
Customer, job, contract, time, payment, and fulfillment systems retain the business facts they own.
- 02
The trusted API owns financial commands
The browser, embedded surface, and integration cannot write financial tables or bypass posting and approval policy.
- 03
PostgreSQL enforces the last line
Transactions, tenant context, constraints, grants, row-level security, immutable audit evidence, and content checks fail closed.
- 04
Portals read the same controlled state
Operators, developers, firms, and embedded products consume one API contract rather than creating separate versions of financial truth.
Choose the next record
Follow the accounting system into the product.
Developer platform
Authentication, canonical events, SDKs, webhooks, idempotency, errors, and sandbox workflows.
Read the build contract →Trust center
Tenant isolation, data protection, availability, recovery, evidence, and independent-assurance boundaries.
Inspect trust evidence →Industry solutions
Apply dimensions, policies, workflows, and reports without forking the financial kernel.
Choose an operating model →Embed the accounting system without inheriting its platform burden.
Start with the sandbox
Send the business event once. Read the resulting books, workflows, reports, reconciliations, and evidence through one production contract.