Tax Reconciliation Workbench

The problem

Tax teams reconcile ledgers across countries. Errors are costly, and a reviewer cannot sign off on something an AI “just decided.” The question: how do you use AI here without losing the reviewer’s trust?

The result

• 100% recall and zero false positives against seeded ground truth (21 seeded errors, 6 error classes).
• Every decision is logged with reviewer, timestamp and reason, and exports as an audit trail.
• One screen for the reviewer: the exception, the explanation, the proposed action, approve or override.

Key design decisions

1. The reviewer’s screen came first, and it set the data model. I cut the product to the one screen a reviewer needs. What that screen must show decided what each record had to contain.
2. AI at the edges, never the core. Plain code finds every exception. AI only explains it and proposes a disposition. It never decides what is wrong and never assigns severity.
3. Humans at the point of consequence. Approve or override is always the reviewer’s call. Filing gates block a return from release while critical or high exceptions are undecided.
4. Visible provenance. Every AI output is labeled with how it was produced and is schema-constrained.
5. Safe by default. LLM mode is opt-in and needs both a key and an explicit flag, so data never leaves without a deliberate choice.
6. Quality is measured, not claimed. An eval panel scores every run against seeded errors: recall, precision, unexplained flags.

How it earns trust: reliability and availability

• It fails safely. Offline mode is the default, using deterministic templates with visible confidence scores and no network calls. An API outage cannot break it, and any AI failure falls back to templates.
• The same input gives the same result. Detection is deterministic, so findings are reproducible and auditable.
• Risky paths are closed. Audit exports are protected against spreadsheet formula injection, and inputs are clamped server-side.
• Access is gated. Public deployments enforce authentication, and the signed-in username is written into every decision-log row.

How it fails safely

• If the AI is unavailable: offline mode is the default. Deterministic explainer templates with visible confidence scores, and no network calls.
• If the AI returns something unexpected: output is schema-constrained, labeled by how it was produced, and falls back to templates on any failure.
• If a reviewer is unsure: the AI never decides what is wrong or assigns severity. The human approves or overrides, and the decision is logged with identity and time.
• If exceptions are unresolved: filing gates block release of the return.
• If data is risky: synthetic data only. LLM mode needs both a key and an explicit flag. Audit exports are protected against spreadsheet formula injection, and inputs are clamped server-side.
• How I know it works: an eval panel scores every run against seeded errors (recall, precision, unexplained flags).

What I would do next

• Test the review flow with real reviewers. I have not run formal user research on it.
• Add keyboard shortcuts for high-volume queues.
• Wire the evals into a release gate.

Skills shown

Trustworthy AI interface design, human-in-the-loop review, audit trails, reliability and fallback design, evals, and fast prototype to production.

All data is synthetic. No PII and no real financial data. This is a personal portfolio project.