One accounting engine for fintech and crypto ventures — always reconciled, so the business can move fast and grow.
Transaction templates · financial hierarchy · rules · counterparties · deals · client accounts
The problem
Large accounting teams spend their days on the same operations — exports from every venue, merged by hand in spreadsheets — and still face a monthly and a quarterly audit.
Without one source of truth, automation and AI stay out of reach, and the business loses the ability to watch its money streams, adapt fast and earn more.
The solution
Every venue, wallet and client feeds one ledger. The routine classifies itself; the few movements that need a decision reach a person once — and become rules.
Reports, client statements and the audit trail come out of the same entries, nothing is re-keyed — and set-up takes a week, not a quarter.
Set-up · 1
A built-in hierarchy of business, financial and counterparty types, with a library of transaction-type templates made for financial companies — payments, income, loans, custody, fees — that fits any company structure.
Every type carries its own fields — a payment asks who and which entity, a loan asks for facility, principal and interest — and compiles into the reporting the business needs.
Set-up · 2
Each account is mapped once to its place in the reports: the balance-sheet or P&L line, and the section of the cash-flow statement. Nobody tags transactions by hand.
Your auditor wants interest paid shown under financing? Change one mapping and every entry follows. The reporting hierarchy — entity, desk, cost centre, project — slices the same entries the way the business asks.
Set-up · 3
The system retrieves account details on its own — SWIFT and SEPA details, crypto addresses — for every account you connect, and maps them to counterparties ranked by value, so the first twenty names cover most of what moves.
Each counterparty carries a default treatment: set it once and every later movement is classified the same way. For a payout book, set it on the account itself — every outgoing movement is a client payout, whoever receives it.
Set-up · 4
A fully customizable builder: any filter on the ledger — field · operator · value — becomes a financial or reporting rule, or a template. Rules are stored as readable JSON, so they can be reviewed, versioned and supported by code.
Preview the effect before it is live: Test shows what would classify, agree, change or be shadowed; Publish shows the before-and-after difference across the ledger before a single row moves.
Set-up · 5
A transaction type covers one movement. Real deals are often several: the client pays on one exchange, you buy on two others, you deliver days later, and a small difference is left at the end.
A deal type describes the whole structure — which movements to expect, how each is recognised, where it posts, how much difference is acceptable and for how long — and what happens to that difference: margin when small, a person when not.
Set-up · 6
The product owns everything before a journal entry: the ledger in native units, classification, rules, counterparties, deals, allocations. The accounting engine (ERP) owns journal entries, partner ledgers, periods and statements.
It runs behind the product, and only a human-confirmed act posts. What the waterfall decided on its own is a proposal — an entry that moves because somebody republished a rule is worse than no entry at all.
Engine offline changes nothing here: the act commits, the row says not yet posted, and one page lists everything waiting, with a Retry.
A day in the product
One screen where the accounting team catches and works the non-standard movements. Everything routine is already classified; what needs a decision is ranked by value, so important movements come first and dust never gets in the way.
Built for speed: bulk actions, and any decision becomes a rule in one step. Why shows the reasoning behind every row; the entry is previewed and must balance before it is saved.
Deals
Attach any movement to a deal from its row. One purchase can be split across several deals — evenly, first come first served, or by hand — never beyond what it holds. Here one 3.5 BTC purchase covers three client deals; 0.8 BTC stays the company's own position.
The deal balance is always computed from the movements. Close it as margin, refund the difference, or leave it as a credit on the client's account.
Client accounts
Each client has one account: every deposit, deal and delivery lands on it, and the balance per asset shows at a glance who owes whom. A prepayment, one wire covering several deals, an instalment, an over-delivery — all just movements on that account.
At period end the balance goes straight into the books: what we hold for the client as client money, what the client still owes as a receivable. The same view exists per venue.
The statement sent to the client is this table, not a second one built for the occasion.
Period end
Closing is a checklist: the action board worked down by value, deals with an open balance settled, client accounts flat. Then set the lock date, with a reason: everything up to it is closed and cannot change.
Every decision, rule change, posting and lock is logged — who, when, why — so the audit trail is already written. After the lock, a movement dated inside the closed period is flagged before anyone touches it.
Let's start building together
Five set-up steps on your own exports, days not months. From then on the books reconcile themselves daily, the close is a checklist, and the numbers are there whenever the business asks — the impact starts in the first month.
Runs on Google Cloud / AWS · SOC 1, 2, 3 and ISO 27001 certified infrastructure · encrypted at restBring one month of venue exports and the first pass runs before the call is over.
Space pauses · ← → move between scenes · F fullscreen · click a segment to jump