Skip to content
NEW

GPU compute is becoming a commodity. See what it takes to make GPU hours interchangeable →

Register for Event
_RECONCILIATION / ENTERPRISE_

Continuous controls over your financial state

Check the relationships inside your ledger and the cash that backs them. Run controls on your schedule, investigate discrepancies, and retain the evidence behind every decision.

Two records. One relationship./01
What you holdCustomer assets$4,100.00−$50.00 at 10:30 UTC
ReconciliationDiscrepancy detectedDifference · −$50.00
What you oweCustomer obligations$4,150.00Unchanged
Checked on your schedule

Define the relationship. We keep checking it.

  1. 09:00Balanced
  2. 10:00Balanced
  3. 11:00Shortfall of USD 50.00
  4. 12:00Shortfall of USD 50.00
  5. 13:00Shortfall of USD 50.00
  6. 14:00Shortfall of USD 50.00

Illustrative Ledger account groups · USD · A balance change at 10:30 is detected at 11:00 UTC.

_BUILT ON LEDGER/

Start with the ledger you already run.

Your balances are already there. Define what must stay true.

Select account groups using the Ledger queries you already write. Compare them with each other or with a balance range. Payments is only needed when a control reads an external cash pool. Unsupported banks and PSPs can supply those pools through the Generic Connector.

How the modules fit together
_01 / DEFINE/

Define the relationships your money must preserve.

Four templates, grounded in financial intent.

Choose the sources, signs, bounds and per-asset tolerances. Reconciliation generates and validates the expression. Check customer funds, treasury limits, subledger parity or external backing with the same control model.

Explore the documentation
Choose a control/02
The relationship

Do customer assets and obligations still net out?

Customer assetsUSD 350.00
Customer obligations− USD 350.00
Observed · tolerance 0.00

350.00 − 350.00 = 0.00

PASS
Net zero

Ledger account groups · signed terms

Illustrative configurations · Tolerance is per asset and defaults to zero for unlisted assets.

_02 / EVALUATE/

Run often. Keep one case per asset and period.

The schedule runs the check. The period groups the results.

Every evaluation is persisted. Repeated failures for the same asset reuse one case within its period, with a rising occurrence count. A new period starts an independent case, so last month’s decision never hides this month’s difference.

Explore the documentation
Two independent settings/03
Schedule · how often we look

Every hour

Runs at :01 UTC · reads at :00:30

24 scheduled reads per day

Period · how we group the results

24evaluations → one asset case

24 hourly evaluations in one UTC day. Repeated failures reuse the same asset case.

All July reads fail in USD: 31 cases across the month.

Independent cases · separate example

Asset2026-07-212026-07-22USD/2
RESOLVED
OPEN
EUR/2
OPEN
No failure

Resolving USD never clears EUR. A new period keeps its own record.

_03 / TAKE ACTION/

Turn discrepancies into cases your team can own.

Detect, notify, investigate and close.

An alert carries the evidence, severity and labels your workflow needs. Deliver transitions through Webhooks, acknowledge the investigation, and record the outcome. A period is green only when it has no open or acknowledged cases.

Explore the documentation
From detection to closure/04

A later check passes, or an analyst records a correction. A business acceptance closes the case through its own accepted_alert event.

reconciliation.resolved_alert
01 / Event
02 / Webhooks
03 / Your consumer
04 / Team queue

Your consumer reads labels such as team=treasury and routes the event. Unchanged repeat failures stay in the history without repeating notifications.

Snooze mutes notifications. It does not stop evaluations, change the status, or make the period green.

_04 / KEEP THE PROOF/

Keep the evidence behind every decision.

Know what changed, who acted, and why it closed.

Each failure preserves the numbers behind it. Every acknowledgement, snooze and resolution remains in an append-only timeline. Return months later and inspect the actual record instead of reconstructing it from exports and messages.

Explore the documentation
Evidence that keeps its history/05

USD/2 / 2026-07-21

subledger-control-parity · Two failures, one case · Illustrative timeline

OPEN

The difference increased to USD 5.00. Occurrence 2 returns the acknowledged case to OPEN.

Recorded byReconciliation
Control accountUSD 2,500.00
Sub-accountsUSD 2,495.00
DifferenceUSD 5.00
ToleranceUSD 0.00
Both sources read at2026-07-21T12:00:30Z
auto

A later check passes

The system closes the case and records the time and passing evaluation.

fixed_by_booking

Record the correction

Keep the author, an optional note, and optional references to the corrective Ledger transactions.

accepted_by_business

Accept the difference

An author and required note explain the decision. Its evidence is frozen; the balances remain unchanged.

A later failure in the same period reopens the case. Previous decisions remain in its append-only timeline.

Explicit source timestamps

Read each source at a defined instant, including different instants for different settlement cycles. A 30-second safety margin applies by default.

Evidence outlives the rule

Editing a rule does not rewrite a recorded evaluation. An acceptance freezes the evidence behind that business decision.

Exact to the smallest unit

Comparisons use arbitrary-precision integers. Large balances keep their last digit; per-asset tolerances stay explicit.

_QUESTIONS/

A few things to know.

01 / Do I need Payments to use Reconciliation?

No. Controls can compare Ledger account groups with each other or with configured bounds. Payments is needed when a configured source is an external cash pool. The Generic Connector brings unsupported providers into Payments.

02 / Does it match individual transactions?

Reconciliation checks aggregate financial state per asset at a point in time. It does not match individual Ledger postings to bank or PSP statement lines.

03 / How are schedules and periods different?

A schedule determines when a rule runs: on demand or on a cron schedule. A period groups its results: continuous, daily, weekly or monthly. Calendar periods use UTC boundaries; weeks follow ISO 8601. The schedule timezone does not move those boundaries.

04 / What is the difference between FAIL and ERROR?

FAIL confirms that a checked asset did not satisfy the control. ERROR means the check could not complete, for example because a source was unavailable. It creates a separate engine.error alert for the operational problem.

05 / How does a case close?

A later passing evaluation closes it automatically. Your team can also record a corrective booking, optionally linking its Ledger transactions, or accept a difference with an author and required note. Acceptance freezes the evidence without changing balances. A later failure in the same period reopens the case and keeps prior decisions in its timeline.

06 / How do we get access?

Reconciliation is an Enterprise module operated through the API. Ledger 2.4.11 or later is required for historical metadata queries. The documentation covers creating a first rule, evaluating it, and operating alerts.

_GET STARTED/

Put your financial controls on schedule.

Define the relationship. Investigate the difference. Keep the proof.