Bring the two records together.
Provider exports and your own order records are read on a schedule, with a named owner for whatever fails to import.
- CSV or API intake
- Duplicate detection
- Import failure alerts
RECONCILIATION FOR TEAMS THAT MOVE MONEY EVERY DAY
Every payment. Accounted for.
Ledger matches what a payment provider says happened against what your own records say happened, and shows you the difference before month end.
RECONCILIATION / SAMPLESIMULATED
Settled78%
Matched70%
Review08
Illustrative figures from the demo below. No live account is connected.
01SOURCE OF TRUTH
03MATCHING RULES
00SPREADSHEETS REQUIRED
Ledger is a fictional product, drawn as a website concept. Every number on this page is simulated.
01 / THE PRODUCT
One question. Answered daily.
Does the money that arrived match the money you expected? Most teams answer that with an export, a formula and an afternoon. Ledger answers it with rules you can read.
Ledger is a fictional product shown as a design concept. It connects to nothing, processes no payments and stores no data beyond this page.
See how a payment moves ↗02 / WHAT IT DOES
Three jobs. One ledger.
3 capability areas
Rules a finance team can read.
Reference, amount and date tolerance, in that order, each with a visible rule rather than a hidden script.
- Reference matching
- Amount tolerance
- Manual review queue
Settlement you can plan around.
Payouts grouped by expected arrival, with the fees shown separately from the sales they belong to.
- Payout grouping
- Fee breakdown
- Exception notes
Capabilities are illustrative. No payment provider, bank or card network is connected to this page.
03 / THE FLOW
Read, match. Explain.
A reconciliation only helps if someone can see why a row did not match.
Two records, one timeline.
Provider settlements and internal orders are placed on the same day view, so a late arrival is visible rather than surprising.
Rules with a visible order.
Reference first, then amount within tolerance, then date. Anything left over goes to a review queue with the reason attached.
One sentence per exception.
Each unmatched row carries a plain reason, so month end becomes a list of decisions rather than an investigation.
INTAKE / MATCHING / PAYOUTS
A product website built around one working demo and one clear access request.
04 / THE DEMO
Run it yourself. Nothing leaves this page.
Four sample payments, three matching rules. Turn a rule off and run the reconciliation again.
| Reference | Amount | Day | Result |
|---|---|---|---|
| A-1042 | 120.00 | 1 | — |
| A-1043 | 64.50 | 2 | — |
| B-2210 | 980.00 | 3 | — |
| B-2211 | 310.20 | 4 | — |
No run yet. Choose the rules and run the reconciliation.
Simulated data held in this page only. Results do not describe any real payment, ledger or provider.
05 / REQUEST ACCESS
Describe the volume. See the fit.
Prepare an access request and download a copy for yourself. Nothing is sent from this form and no account is created.
ACCESS REQUEST
Build a product like this with Elvarnue ↗
The request is assembled on your device so you can see which details a product team asks for before a first call.
Make the product provable in a minute.
A payments product of your own ↗THE BUSINESS BEHIND THE DESIGN / ELVARNUE
Let a buyer try the product before the sales call.
Fintech products, payments teams and finance software for small operators.
The problem this addresses
Finance software is hard to evaluate from screenshots. A small, honest demo that runs in the browser and states its limits earns more trust than a feature list.
Explore the interactions
- Toggle the matching rules and run the reconciliation.
- Read why a row is unmatched instead of a bare count.
- Prepare an access request around volume, sources and the current process.
What we could deliver for you
A responsive product website with a working demo, pricing structure, security and data pages, and a scoped request form. A production reconciliation service, provider integrations and compliance work are separate engineering scopes.
What we need to get started
A defined demo scenario, permission to describe the product's limits, security and data statements you can substantiate, and the objections your sales team hears most.
Design decisions
- The demo ships with sample data and says so on the panel, rather than implying a live account.
- Matching rules are visible and switchable, because a black box is exactly what buyers distrust.
- No compliance certification, licence or uptime figure appears; a concept page cannot substantiate them.