Reconciliation that remembers: closing the loop across runs
Most reconciliation tools forget everything when a run ends. ReconPe now carries exceptions across runs, links settlements that arrive late, and spots patterns in recurring behaviour.
Ask anyone who's done reconciliation for a year and they'll describe a particular kind of frustration. You close the books on February, flag a ₹12,400 variance for vendor X as an open exception, and move on. A month later in the March run, a ₹12,400 surplus shows up in the bank — the vendor settled late. You remember. You remember so clearly that you go back, find the open exception from February, and close both together. Your reconciliation tool, meanwhile, has no idea either event was related. It treated each run as an island and made you do the bookkeeping in your head.
This month we shipped a change to ReconPe that fixes that. Exceptions used to be locked inside the reconciliation that produced them. Now they live in an organization-wide pool that survives run boundaries. When today's run produces an exception, ReconPe automatically checks the pool for an opposite-sign match from earlier runs — the late settlement arriving, the surplus that explains last month's shortfall, the double-entry that finally clears. If it finds one, it surfaces a candidate: 'this looks like the settlement of exception #1832 from Feb 14.' One click closes both sides together. The system does the correlation. You make the call.
Underneath, the mechanism is deliberately simple. Every eligible exception gets a fingerprint — a deterministic hash over the counterparty, amount, and direction. Cross-run matching is a single indexed database lookup, not an AI inference. This matters because it means the correlation is cheap to run, easy to explain, and provably correct. You can click any suggested link and see exactly which fields matched. No black box.
Users who said 'no, that's not actually the same event' teach the system to stop proposing that pair again. That feedback is persisted per-organization, so different tenants can disagree on what constitutes a settlement and both be right. Open items that never resolve age out of the pool after 180 days — still searchable for audit, but no longer active candidates.
The second shift is smaller but compounds. Once three confirmed settlements exist for a counterparty, ReconPe tags that counterparty with a pattern — for instance, 'late settler, average lag 5 days.' The tag shows up on any future exception for that same counterparty as an amber banner: 'recurring pattern detected.' Your finance team no longer needs institutional memory to know that vendor Y always rounds down by a few rupees, or that client Z consistently pays on T+5. The system surfaces it before the question even comes up. This is what makes the reconciliation agent feel, for the first time, like it actually remembers.
That word — 'agent' — is also new. ReconPe's chat assistant now has conversational access to all of this. Ask 'what's going on with vendor P?' and it calls the pattern lookup, reads the tag, and narrates: 'Vendor P has 3 linked settlements averaging 5 days late. This is a consistent late-payment pattern.' Ask 'how many open exceptions do I have?' and it reads the pool total. Ask 'is there a match for exception #418?' and it runs the cross-run lookup and reports back. The chat agent and the UI share the same server-side phrasing so you get consistent answers regardless of where you're looking.
None of this requires the user to change anything about how they work. Existing reconciliations, existing rule sets, existing workflows — unchanged. The memory feature is additive: it kicks in automatically, learns from what you confirm, and gets more useful the longer you use ReconPe on the same counterparties. That's the distinguishing property we're building for. Reconciliation is one of the very few domains where the same problem recurs every period against largely the same actors. A stateful system compounds. A stateless one plateaus.
This is the shape the product will keep growing into over the next quarter: more pattern types (rounding tolerances, date-rollover trades, quick-settler vs late-settler), smarter entity recognition when vendor names drift ('AMZN MKTPLC IN' and 'Amazon Seller Services' are the same entity), and deeper chat reasoning about what each pattern implies for your books. If any of this sounds relevant to the problems you're trying to solve, you're the kind of operator we're building for — and we'd genuinely like to hear from you.