Continuity ends when the books agree
Delivering an operation is not the end of it. A bank, a utility or a health system needs to know that what happened in the field is exactly what its own records say happened, including everything captured while there was no network. wede checks every operation it carried against your own records and shows, for each type of equipment and for each day or hour, what your records confirmed, what differs, what is still waiting and what was never confirmed, with the reason. This is the question an auditor, a regulator or a board asks after an outage, and wede answers it with one view instead of a week of spreadsheets.What is checked against what
On one side, the operations wede carried: each one immutable, with its amount, currency, direction, reference, the device that captured it, whether it was captured online or offline, and the time of capture on the device. Event types marked as ledger operations in your catalog, such as payments, withdrawals, deposits or equipment readings, are recorded this way. On the other side, your own records, grouped in sources: a bank statement, an ATM journal, the counter of a payment terminal, the log of a piece of equipment, or any other record your systems keep. Every hardware device you register on Devices gets its own source automatically. Your systems send the records, up to 500 per request:Outcomes and reasons
Every record ends with an outcome and a reason, both fixed codes your systems can rely on.
Operations with no record yet are shown as waiting while they are within the time window of the source that should confirm them, 24 hours when there is none, and as not confirmed after that. Each outcome is sent to your systems by signed webhook (
operation.reconciled, operation.unmatched) and every view exports to CSV.
A source tied to a machine, such as the journal of an ATM or the counter of a payment terminal, only ever confirms operations of that machine. A record from one ATM can never confirm a payment taken on a POS terminal, even with the same amount at the same minute.
Currencies, quantities and units
Amounts are kept in the minor units of their currency, with the number of decimals that currency uses: none for JPY, two for EUR, three for KWD. An amount sent in decimal is converted once, with the decimals of its own currency. Many operations are not money: the energy of a charging session, the water or fuel delivered, the dose given. An operation and a record can carry a quantity and its unit as captured, for example 12.4kW.h, 351.2 m3 or 5 mL. wede keeps them exactly as they came and never converts them. A record without an amount is matched by quantity, unit and time; a record with both is matched on both. The same number in another unit is reported as unit_mismatch, never as a match. Quantities appear next to amounts in the dashboard and in the CSV exports.
Reversals
A reversal is an operation of its own, recorded as captured, and tied to the operation it reverses when it carries the original reference (original_ref, original_rrn, original_stan or a similar field). The ledger shows both sides: this operation reverses that one, that one was reversed. Reversals that are not tied to an operation are counted on their own, so nothing is silently left open. wede does not check the amount, the deadline or the eligibility of a reversal: that stays with your organisation and its partners.
When your record carries a reference shared by more than one operation, for example a payment and its reversal, the direction, the currency and the amount decide which one it confirms. If more than one still fits, the record stays ambiguous.
By equipment and by time
The Reconciliation page in the dashboard starts with one table: each line is a period, a day or an hour of capture on the device, and a type of equipment. It shows the operations carried, how many were confirmed, how many differ, how many wait, how many were never confirmed and how many of your records have no operation. Any number opens the operations behind it, with the device, the amount, the reference and the record that confirmed it. After an outage this reads as a sentence: on Tuesday between 14:00 and 17:00 the ATMs captured 1,200 operations offline, 1,198 were confirmed by the bank journal, 2 differ and these are they.Your decisions
Finding a difference is half of the work. The other half is what your organisation decided about it, and an auditor asks for both. For every operation or record that did not reconcile, your team in the dashboard or your systems through the API record the decision:ledger_id) or one of your records (record_id), with an optional note and your own reference, such as a case number. Up to 500 decisions go in one request as { "resolutions": [...] }, with one result per decision. A decision never changes the operation: each one is a new entry, the history is kept, and the latest one counts. An operation your records already confirmed has nothing to resolve and returns 409 nothing_to_resolve. Each decision is sent by the reconciliation.resolved webhook, without the note.
Recording decisions takes the same permission as sending records: the organisation’s administrators, its technical staff and its API key. Everyone who reads reconciliation sees the decisions and who recorded them.
Closing each day
At the end of a day, a POS batch, an ATM journal or a bank statement has a total. Send it, per currency and direction, for each source:closed when the totals agree, and difference otherwise, with each difference (yours minus wede’s). Who sent each closing, and when, stays on record; sending a day again keeps the earlier closing and the new one counts. A day that has not ended returns 409 day_not_over.
If operations arrive after a day was closed, for example from a device that was offline, the list of closings shows what wede counts now next to what was closed, so the day can be closed again. Days with operations and no closing are listed too. Each closing is sent by the reconciliation.period_closed webhook, without amounts.
Each device, in one line
GET /v1/reconciliation/devices and the By device table in the dashboard show, for every device, its operations by state, your records with no operation from a source of that device, how many have a decision, and whether everything the device sent has arrived. A device with something open, or with operations that should have arrived and did not, is marked for attention and listed first.
Proven end to end
In October 2026 we ran the full cycle in our test environment with a simulated POS terminal and a simulated ATM. Nine operations (payments, withdrawals and two reversals) were captured with no network, three hours before they were sent, and synchronised out of order. One batch was sent twice. One message was altered after it was signed. The records then arrived from three sources: the terminal counter, the ATM journal and a bank statement, with one amount that did not match and two records that matched no operation.
Every step is in the audit log. The test used simulated equipment, not a production deployment.