AI Reconciliation Workspace

Automated matching handles most reconciliation volume without friction — it's the remainder that costs a company real time. When a transaction can't be matched automatically, a finance analyst has to piece together evidence scattered across bank feeds, ERP records, and email threads just to understand what happened, let alone resolve it. That fragmentation is what actually delays financial close, not the matching itself. And a delayed close isn't a minor inconvenience — it's the kind of thing a controller or CFO notices immediately, because it pushes back every downstream reporting deadline.

I defined the product thesis, the workflow structure, and the rules governing where AI is allowed to act versus where a human has to. The decision I'd defend hardest is splitting the product into two distinct workflows instead of one: monitoring cycle readiness (which runs are at risk, across the whole portfolio) and investigating an exception (resolving one case, with full evidence). Most reconciliation tools collapse these into a single exception list — but a controller and an analyst are asking fundamentally different questions at fundamentally different zoom levels, and forcing them through the same view was the thing I decided not to do.

A controller and an analyst are asking fundamentally different questions at fundamentally different zoom levels — forcing them through the same view was the thing I decided not to do.

The product skeleton runs Cycle Readiness Dashboard → Initiate Run → Run Details → Exception Queue → Exception Investigation Workspace → Controller Review → Export/Sync → Audit History. Initiating a run moves a period through select, upload, validate, normalize, clean, match, and exception generation before anyone touches an exception by hand. The readiness workflow sits above all of it — an analyst or controller can see every active run, spot which ones are blocked, and jump straight into the one that needs attention, instead of hunting through a flat queue for what actually matters today.

Reconciliation is a domain where the AI cannot be allowed to guess quietly — a wrong auto-approval touches a financial statement. So the split between deterministic logic, AI assistance, and human judgment isn't a nice-to-have, it's the core design constraint. Deterministic rules own anything with one correct answer: file schema checks, date formatting, duplicate detection, exact matching. AI is scoped to the ambiguous middle — suggesting matches, summarizing evidence, surfacing related records, generating explanations — but every one of those outputs has to show its supporting evidence, by rule, not by convention. The human owns everything irreversible: approving or rejecting a suggested match, resolving or escalating an exception, final sign-off on a run. Overrides require a stated reason, which turns every disagreement with the AI into a data point instead of a silent rejection.

I kept live ERP integration, autonomous approvals, real-time reconciliation, and predictive fraud detection out of the MVP — CSV upload and a simulated ERP sync are enough to prove the investigation workflow without the risk of an AI system touching production financial data before it's earned that trust. One judgment call I made rather than treating as settled: readiness isn't based on exception count alone, since a run with three blocked high-risk cases is less "ready" than one with twenty trivial ones — that weighting is a business rule I'd want to validate directly with a controller before shipping. Since this is a portfolio build, I'm not claiming close-time or backlog numbers I don't have. What I'd track in a real deployment: AI suggestion acceptance rate and override rate together (they tell you whether analysts trust the AI or are rubber-stamping it), confidence calibration (whether the AI's stated confidence actually predicts correctness), and exception resolution time as the outcome metric that matters to the business.

This is the project that best proves I can design AI for a domain where being wrong has real consequences, not just an annoying one. Evidence-required recommendations and reason-required overrides aren't UX polish — they're the mechanism that makes an AI system auditable in a regulated workflow. That's the specific muscle I'd bring to any enterprise product where the model's output is about to become a financial, legal, or operational decision someone has to stand behind.