Engine Core
Runs every action as a controlled transaction: receiving, movement, reservation, picking, packing, shipping, billing, approvals, holds, releases, adjustments, enforcing permissions, validation and sequence before a single record changes.
Coming soon
Operations and accounting, in the same transaction.
Corva is a multi-tenant ERP for distribution and wholesale. Receiving a pallet, shipping an order, billing a customer: each action commits its state change, its inventory ledger entry, its audit record and its accounting posting together, in one database transaction. Nothing drifts out of sync, because nothing can be written on its own.
One note when early access opens, at hello@corvaerp.com
One database transaction
ship_sales_order
- Order statereserved → shipped
- Inventory ledger−24 EA · lot · location
- Audit recordwho · what · when · permanent
- GL postingCOGS · revenue · balanced
Commit
All four, or none of them.
The operational spine
Goods in, goods out, money settled: one continuous chain.
Corva models the physical movement of goods and the money around it as a single chain of controlled transactions. Each stage hands the next one a record it can trust, and every hand-off is written down.
The interface starts an action; the core decides the result. Screens never write to your business records directly. They invoke a named business transaction that checks permissions and rules first, then writes state, ledgers and audit together.
Capabilities
Built for the parts of ERP that can't be retrofitted.
Atomicity, audit, accounting truth, isolation and concurrency are foundations, not features. They are the things you cannot add to a system later, so Corva starts with them.
Atomic business transactions
Every business action is a named, controlled transaction: state change, inventory ledger, audit record and accounting posting commit as one unit, or the whole thing rolls back. There is no side door. No screen, script or integration can write to transactional data any other way.
How the core worksA permanent product audit trail
Every unit's full history is kept: received, moved, reserved, packed, shipped, corrected, with the person and the authority behind each step. Nothing is ever hard-deleted: a mistake is fixed by a recorded correction that leaves the original visible.
See the audit trailGAAP-native accounting
The operation produces its own accounting. Balanced double-entry postings are written inside the same transaction as the goods movement, with ASC 606 revenue recognition, FIFO and weighted-average costing, and subledger-to-general-ledger reconciliation built in.
Inside the engineTenant isolation in the database
Row-level security is enforced by Postgres itself and fails closed: without a valid tenant context a query returns nothing at all. Your data is not separated by a developer remembering the right filter; it is separated one layer below the application.
How isolation worksCorrect under concurrency
Two pickers racing for the last case cannot both win it: the database serializes the claim, so you can't oversell. Document numbers stay gapless under load, and operations are idempotent: one click or five produces exactly one shipment.
Concurrency guaranteesEvery figure traces to an event
Quantities, costs and balances are derived from ledgers rather than stored as editable fields, so numbers reconcile by construction. Follow a line on a financial report down to the subledger, to the operation that produced it, to the goods that actually moved.
ReconciliationTrust architecture
Three cores under every screen.
Between the interface and your business records sit three required layers. They are present from the first release, and they are what future modules build on instead of patching around.
Accounting Core
Gives every operation its financial meaning at the moment it happens: cost captured on receipt, cost of goods and revenue on shipment, a receivable on billing, settlement on payment, balanced and reconcilable to the general ledger.
Audit Trail Core
Captures the permanent record: business events, approvals, overrides, status and quantity changes, financial and inventory movements, configuration changes, and security activity. All of it kept, none of it editable.
Four invariants we don't get to break
enforced by automated gates on every change- No write to transactional data outside a named business transaction.
- Tenant context is required; row-level security fails closed.
- Every financial action writes one balanced posting, in the same transaction.
- No hard deletes: history is permanent; corrections are recorded, not erased.
Corva is specification-first: every mechanism is specified and certified before a line of code ships, and isolation, no-oversell and posting-balance behavior are covered by automated test gates that run on every change.
Coming soon
Corva is in active development.
If you run a distribution, wholesale or supply business and you're tired of your operations and your books telling different stories, tell us about your operation. We'll let you know when early access opens.
hello@corvaerp.com