Inspiration

Construction is a 13 trillion dollar industry, and it is one of the least digitised. We kept coming back to one boring, expensive fact: on a large project, somewhere between 1 and 5 percent of the budget quietly leaks out through billing errors. On a 500 crore project that is 5 to 25 crore rupees, gone. And almost nobody is stealing it. It leaks because invoices are checked by hand.

A clerk opens the purchase order in one system, digs the signed contract out of a folder, pulls the invoice out of email, and eyeballs rates, quantities, tax and retention under deadline, hundreds of times a month. Duplicates get paid twice. A vendor bills 450 rupees a unit when the contract locked 410, and it sails through. The errors are structural, not malicious. That is exactly the kind of problem AI should be solving, and we were surprised nobody had properly built it.

What it does

LedgerLens is an AI auditor for construction procurement. It reads every incoming invoice, matches it against both the original purchase order and the signed contract, and flags every discrepancy before the payment is approved.

For each invoice it produces a single Audit Report:

  • A red, amber or green verdict with a risk score.
  • Every flagged line item, with the rupee impact spelled out.
  • A plain-English, cited reason for each flag, for example: "Line 4: billed Rs 450 per unit for TMT steel. Contract Clause 4.2 locks Rs 410. Overbilled by Rs 1,20,000 across 3,000 units."
  • A recommended action (Approve, Hold, or Query the vendor), and it can draft the vendor query email itself.

It catches overbilling, duplicate invoices, quantity mismatches, unapproved rate changes, scope creep, wrong tax, retention errors and out-of-contract charges. A 30-second decision instead of 30 minutes of manual cross-checking.

How we built it

LedgerLens is a true 3-way match engine, not a chatbot. Four pieces work together:

  1. Document intelligence (VLM plus layout-aware extraction). Construction invoices and POs are messy, tabular, stamped and inconsistent across vendors. We extract structured line-item tables, not just raw text, and we handle scanned and photographed documents.
  2. RAG over the contract. The signed contract is long and dense. For every invoice line we retrieve the specific governing clause (the rate schedule, retention terms, GST treatment) and reason against it. This is what lets us cite a clause instead of guessing.
  3. A deterministic reconciliation core. Exact-number matching happens in code, so the system never hallucinates a rupee figure. The LLM sits on top only for the semantic part, recognising that "TMT Bar Fe500D" on the invoice is the same SKU as "Steel reinforcement bar 500D" on the PO.
  4. An explainability layer. Every flag is tied back to a source line and a contract clause, so the output is auditable, which matters more than anything for money decisions.

The interface is a single-screen dashboard: drop an invoice, get the audit report.

Challenges we ran into

  • Trust vs. hallucination. We could not let an LLM invent a number on a document about money. Splitting the work, deterministic engine for the maths and the LLM only for semantic matching and explanations, was the key design decision.
  • Messy real-world documents. No two vendors format an invoice the same way. Getting reliable line-item tables out of scans and photos was harder than plain OCR and pushed us toward a vision-language approach.
  • Clause-level grounding. Matching a single invoice line to the one contract clause that governs it, and nothing else, took careful retrieval design so the citations stayed precise.
  • Scoping for the deadline. Deciding what proved the idea (the end-to-end flow on a realistic invoice with a hidden overcharge, a duplicate line and a retention error) versus what was polish.

Accomplishments that we're proud of

  • An end-to-end flow that takes a realistic construction invoice and catches three different problems (an overcharge, a duplicate and a retention error), each cited and quantified in rupees, in seconds.
  • Going deeper than an API call: a genuine combination of VLM, RAG and a deterministic 3-way match, rather than a prompt wrapped around a chatbot.
  • Output a non-technical project manager can act on immediately, because every flag is a plain sentence with a rupee number and a clause reference.

What we learned

  • In a domain where the output drives payments, explainability and determinism are features, not extras. A confident wrong answer is worse than no answer.
  • The biggest edge came from being specific. "AI for procurement" is vague; "a clause-level 3-way match that quantifies leakage" is a product.
  • Construction data really is disconnected PDFs and spreadsheets, which is precisely why an AI layer that reconciles them has so much room to create value.

What's next for LedgerLens

  • Learn each vendor over time. Every reconciled invoice teaches the system a vendor's habits (for example, consistently rounding quantities up), so it gets sharper with use.
  • Go agentic. Beyond drafting the query email, automatically open, track and close disputes with vendors.
  • Portfolio-level risk. Roll findings up across every vendor, PO and site to surface leakage patterns for an entire company, not just one invoice.
  • Sit on top of the existing supply chain. LedgerLens is the natural procurement-integrity layer on top of a platform that already holds the PO and material flow, like Kaya.

Built With

Share this project:

Updates

Submission history