LedgerLens

## Inspiration

Month-end close still involves too much manual spreadsheet comparison. Finance teams must decide whether a payment matches an invoice, whether one payment covers several invoices, or whether an invoice is missing entirely. These are high-stakes decisions: a wrong match can create duplicate payments, delayed vendor follow-up, or inaccurate financial reporting.

I built **LedgerLens** to make reconciliation evidence-led rather than spreadsheet-led. Our goal was not to replace accountants, but to give them a clearer starting point: what happened, why it was flagged, and what evidence supports the decision.

## What it does

LedgerLens is a review-first reconciliation workspace for the Office of the CFO.

Users upload two CSV files:

1. A **vendor statement** containing invoices from a supplier.
2. A **company ledger** containing payments recorded by the company.

LedgerLens then identifies and explains:

- Exact invoice-payment matches
- Combined payments, such as ₹5,000 + ₹3,000 = ₹8,000
- Partial payments
- Missing or unpaid invoices
- Duplicate invoice numbers
- Ambiguous payments that require human judgement

Every flagged item includes the invoice/payment evidence, amount comparison, and a human decision workflow: **Confirm, Reject, or Flag as dispute**. Reviewers can add notes and export a review summary.

The product also protects users from common upload mistakes by warning when vendor and company files are reversed or when files use different currencies.

## How I built it

I built LedgerLens as a Next.js and TypeScript application with a deterministic matching engine.

- **Frontend:** Next.js, React, and a calm blue/beige accountant-focused interface
- **CSV processing:** PapaParse
- **Matching engine:** deterministic TypeScript rules for exact, combined, partial, duplicate, and missing-record cases
- **Evidence model:** each finding links back to the source invoice/payment IDs, dates, references, and amounts
- **Human review:** Confirm, Reject, Dispute, reviewer notes, review history, vendor view, and exportable text reports

For example, combined reconciliation checks whether:

$$
\text{Invoice}_1 + \text{Invoice}_2 = \text{Payment}
$$

So:

$$
₹5{,}000 + ₹3{,}000 = ₹8{,}000
$$

is presented as a reviewable, evidence-backed finding rather than an unexplained automatic action.

I also used **Agent Orchestrator** to manage parallel Codex sessions. Separate worker sessions handled the accountant UI, deterministic matching logic, evaluation tests, live CSV handling, and targeted bug fixes. Each workstream used Git branches and pull requests so changes could be reviewed and merged safely.

## Challenges I faced

The biggest challenge was making the reconciliation logic realistic without building an entire ERP system.

I had to carefully distinguish between:

- a true exact match,
- a payment split across multiple invoices,
- a partial payment,
- a duplicate invoice,
- and an unrelated payment.

Early testing exposed important edge cases. For example, a single ₹2,500 invoice and ₹2,500 payment was initially treated as a combined payment, and duplicate records were mistakenly displayed as a rupee value instead of a duplicate count. I fixed these issues by prioritizing exact matches, consuming matched records so they could not generate contradictory findings, and improving how duplicate cases are displayed.

Another challenge was input clarity. Users can easily upload the vendor statement and company ledger in reverse. I redesigned the upload experience with clearly labelled source cards and validation that detects reversed files and mixed currencies before matching runs.

## What we learned

I learned that finance automation is not mainly about producing an answer quickly. It is about producing an answer that an accountant can trust.

The most valuable design decisions were:

- showing evidence instead of only a confidence score,
- keeping a human reviewer in control,
- using deterministic logic for financial calculations,
- designing around realistic exceptions instead of only happy-path matches,
- and testing the product with deliberately messy reconciliation cases.

I also learned that multi-agent development works best when tasks are scoped clearly, isolated into branches, and verified through tests and review before integration.

## What’s next

Next, I would add support for more real-world statement formats, configurable matching rules, richer audit trails, and accounting-system integrations. I would keep the core principle unchanged:

**LedgerLens should help finance teams make better decisions, not make irreversible decisions for them.**