Reconciliation

The job

A finance team reconciles a bank statement against its records. Many entries match by deterministic rules. A small set needs investigation, a decision, or a reply from an outside counterparty. Completion means each discrepancy is resolved or clearly remains an open case for follow-up.

Ironflow has a runnable reconciliation example that combines a rules-first pass with agent triage and human approval. It gives you a concrete execution pattern to evaluate; your real statement source, matching rules, and external message provider are application integrations.

The flow

The statement starts a reconciliation run. A deterministic step matches routine transactions. Remaining entries form cases grouped by counterparty. Each case starts its own run, with model triage, approved outreach, and a durable wait for the counterparty’s reply.

A confirmed resolution can contribute an application-defined matching rule for future statements. Staff see the current cases through a projection. The rule’s scope and the evidence needed to authorize it belong to your matching policy; storing a resolution does not make every learned rule correct.

The difficult moment

The message provider accepts an outreach request, then the worker dies before the durable step result is persisted. On recovery, the unfinished step can run again. The example supplies a stable provider idempotency key so the repeated request does not produce another delivery.

Another pause happens when the counterparty takes days to answer. A durable wait preserves the run’s place without holding a worker. The application can emit a deadline event to route an unanswered case into follow-up; the example uses a sweep for its demonstration deadline behavior.

Ironflow’s role

Durable steps support deterministic matching, tool/model calls, and outreach. Events start independent case runs. Approval gates keep external contact behind a human decision. Correlated replies resume the right case. Entity events and projections can retain the explicit case facts and derive the operational queue.

The example implements redaction and action validation in application code. A production application needs its own data-access rules, provider contracts, deadline policies, and matching model. Inspect the tutorial’s stated limits before adopting the example’s simplified learned-rule and shared-memory choices.

Implementation sketch

This is an illustrative flow:

1. Match a statement by deterministic rules in a durable step.
2. Emit a case request for each unresolved group.
3. Redact model inputs and validate the proposed action.
4. Wait for authorized outreach approval.
5. Send with a stable provider idempotency key.
6. Wait for a matching reply or application deadline event.
7. Record resolution and apply approved matching rules where appropriate.

Starting point

• Resolve a reconciliation exception walks through the runnable example, rules-first matching, approval, external reply, learned rules, and the application’s stated limits.
• Step primitives explains durable calls and correlated waits that support the case lifecycle.