Operations

Reconciliation

When what you observed and what you expected disagree, someone has to work it. Reconciliation is the operations layer that turns a payment exception into a case — with assignment, notes and an immutable audit trail — while keeping the workflow strictly apart from the payment’s truth.

The problem

Real payments arrive underpaid, overpaid, late, pending or reorged. Handling them in a spreadsheet loses the trail; handling them by editing the payment record corrupts the one thing you must be able to trust. You need a workflow that records who did what — without ever changing what happened on-chain.

BLOCKCHAIN_TRUTH != OPERATIONS_WORKFLOW_STATE

What StoneReason does

Opens a case on exception

When Payment Truth and the obligation disagree, a case opens with the exception class — underpaid, overpaid, late, unestablished, reorged.

Gives it a workflow

Acknowledge, assign, note, resolve. Every action is recorded with who and when, in an audit trail that is append-only.

Links the evidence

Each case links the Payment Passport it concerns, so the truth is one click away and never copied into the workflow.

What StoneReason does not do

No rewriting truth. Resolving, dismissing or annotating a case never changes the payment record or the Passport. Workflow state and blockchain truth are separate stores.

No custody. Reconciliation moves no money; it organizes the work around money that already did or did not move.

No silent closure. A case’s history is immutable — you can see every state it passed through and who moved it.

No guessing the cause. The exception class is derived from the observed axes, not assigned by a heuristic.

Live on this deployment

Reconciliation is live. Cases, standings, assignment, notes and the immutable audit trail run today over the Payment Truth a session produces. Because it is a workflow over known truth, it does not depend on any additional network being observed — it depends only on there being a payment obligation to reconcile.

A case, kept apart from the truth

Who this is for: finance, operations and support teams that have to resolve the payments that did not go exactly as expected — and need an auditable trail of how each one was handled.

Input: a payment whose truth and expectation disagree.
Output: a case with a workflow state, an assignee, notes and an immutable history — linked to its Passport.

In the docs →