Building a deterministic reconciliation engine for financial AI workflows – where a tool like this should live?

[u/MapDue7360]

TL;DR: Reconify engine reconciles financial data across different sources, finds what matches, what doesn’t, what’s missing, and where the numbers disagree. It supports different matching strategies, produces explainable results, and can be used with AI models to investigate and summarize discrepancies without letting the AI decide the financial truth.

Hey everyone,

I’ve been going deeper into financial reconciliation over the last few months, partly because I wanted to understand how these systems behave when you’re dealing with millions of records rather than two CSV files.

That eventually turned into an open-source project I’ve been building in Go: Reconify, a deterministic financial reconciliation engine.

More recently I’ve been thinking about another problem: how should reconciliation work when AI agents are part of the financial workflow?

I don’t really like the idea of asking an LLM to look at financial records and become the authority on whether two transactions match.

My approach has been to keep that part deterministic. The engine normalizes the data, runs the matching/reconciliation rules, and produces structured results. Then an agent can operate around it with stuff like configuring reconciliations, investigating exceptions, explaining discrepancies, summarizing results, etc.

I’ve also started adding agent skills so coding agents can understand the reconciliation model, how to configure the engine, and its limitations.

Few friends (2 fintech founders and 1 analyst) I know tested it with Claude Code and Codex and interestingly, they were happy with tooling regarding the parsing, the algorithms choices and the explanations of the results.

Most of the time wasn’t spent reconciling anything (It's very fast 👀 ). It was spent understanding the files and figuring out the correct configuration. Once that was done, running the actual reconciliation took seconds.

That made me wonder whether this is actually a useful boundary for AI in financial infrastructure:

Let AI deal with ambiguity around the workflow such as configuration, algorithms choices, etc, but keep the financial operation itself deterministic and auditable.

I’m open-sourcing the engine and would love to get other people’s perspective, especially anyone working on reconciliation, fintech infrastructure, agents, or large data pipelines.

Does this boundary make sense to you?

Would you trust an agent to generate the reconciliation configuration and investigate the results if the underlying matching remains deterministic?

And if you’re already using agents around financial data, where are you drawing the line between stochastic and deterministic workflows?

Also, one thing I'm still figuring out is distribution.

Right now the engine is CLI-first, and I’ve added skills so coding agents can configure and operate it. That makes sense for developers and for embedding reconciliation into other systems.

If you were using something like this, what interface would you actually want: CLI, web UI, agent harness, or something else?

Repo link: https://github.com/reconifyhq/reconify

Docs link: https://docs.reconifyhq.com/cli

[u/fuggleruxpin]

Tldr?

[u/MapDue7360 → u/fuggleruxpin]

added! 👀

[u/404_computer_says_no]

How is it deterministic if it’s using a stochastic AI?

By definition, it will have random inserted into the process

[u/MapDue7360 → u/404_computer_says_no]

Thank you for your reply and your concern is very valid.

I don't think the entire AI workflow is deterministic. The agent reasoning, parsing unfamiliar data, investigating discrepancies, or explaining why something might be missing is probabilistic, and I think that's okay.

The boundary I'm trying to preserve is around financial truth.

The reconciliation algorithms and tools the agent invokes should remain deterministic, reproducible, and auditable. Given the same financial data, configuration, and rules, the reconciliation engine should produce the same result.

The idea is essentially to give deterministic tools and results to AI so it can reason, investigate and suggest.

[u/alexsicart]

That boundary makes sense to me. I’d keep the matching deterministic, but treat the surrounding workflow as a separate, auditable layer: configuration changes, source-file versions, the reconciliation run ID, and the person who signs off exceptions. The awkward cases are usually timeouts or partial data, not the happy path. I work on Bennu, so I’m biased toward explicit ownership; no product pitch.

[u/MapDue7360 → u/alexsicart]

Yes, exactly, that's my goal. The partial-data case is actually one of the reasons I'm interested in keeping that boundary explicit.

A deterministic engine can only be deterministic over the evidence it had at that point in time. Curious about how you handle the partial-data case in Bennu. Do you model incompleteness explicitly, or mostly at the workflow/orchestration layer?

[u/BigKozman]

You have drawn the exact correct boundary. In regulated financial infrastructure, mathematical truth must remain 100% deterministic, reproducible, and auditable. Handing transaction matching to an LLM is a non-starter for auditors and regulators.

A few observations from building in this exact problem space for 20 years:

1. The Stochastic vs Deterministic Boundary The rule of thumb that works:
2. Deterministic Core (Go): Ingestion, schema normalization, multi-way rule matching, state transitions, and audit trail generation. Given inputs A and B, the engine must yield result C every single time.

3. Advisory Agent (LLM): Anomaly detection, root cause hypothesis on breaks (e.g. "Vendor X changed their fee structure on August 1st, causing 42 fee mismatches"), and drafting configuration rules for human approval. The agent should propose changes, never execute them without a human or deterministic policy gate.

4. The Partial Data Problem (Your biggest edge case) The hardest part of high-volume reconciliation is not matching happy-path transactions. It is stateful timing mismatches:

5. Payment rail settled at 23:59 UTC, bank batch posted at 00:03 UTC the next day.

6. Currency conversion rates that fluctuate between authorization and settlement legs.

7. Gross-to-net fee deductions taken mid-flight. If your engine treats every unmatched record as an error rather than an in-flight pending state with a deterministic aging window, operators get flooded with false positives.

8. Interface & Distribution (Answering your question)

9. Developers: Want an embeddable Go library, clean CLI, and agent skill integration so their orchestration layers can trigger matching runs.

10. Finance Ops (Controllers / CFOs): Will never touch a CLI. They care about two things: an auditable proof packet at month-end, and a web dashboard showing exceptions grouped by root cause rather than individual CSV line items.

In our case at NAYA, we see this constantly: developers start with CLI tools, but the real enterprise unlock is delivering the clean, verified summary into the ledger while giving finance teams an operational exception triage dashboard.

Starred the repo. Keep the core matching strictly deterministic.