Setu | Devpost

Inspiration

Construction is a multi-billion dollar industry, but the backend billing process is surprisingly archaic. We noticed a massive disconnect between "site reality" and "office reality." On-site, workers accept delivery notes for materials. In the office, accounts teams pay invoices based on Bills of Quantities (BOQs). When those two pieces of paper don't match, whether due to genuine error, miscommunication, or intentional leakage, 3companies end up paying for materials they never actually received. We realized this "billing leakage" isn't a complex financial mystery; it's a data-matching problem waiting to be automated.

What it does

Setu stops billing leakage before invoices are paid. It reads unstructured, messy delivery notes and invoices, matches them against the project's BOQ, and instantly flags discrepancies. Instead of just saying "there's an error," it calculates the exact financial impact of the leakage. For example, if 0.2 MT of excess steel is delivered and billed, Setu catches it and highlights the exact cost of that mistake so the accounts team can hold the payment.

How we built it

We quickly realized that trying to make an AI do everything was a bad idea. If an LLM reads a document and hallucinates a number, the financial impact is disastrous. So, we split Setu into two distinct layers:

AI Extraction Layer: We used LLMs to read unstructured delivery notes and invoices. The AI extracts the raw materials, quantities, and rates, acting like a fast data-entry clerk.
Deterministic Reconciliation Engine: This is the core of Setu. Once the AI extracts the data, it passes it to a traditional logic engine that does the actual math. The AI is not allowed to guess the final numbers.

For example, if a BOQ lists TMT Steel at a rate of ₹70,000/MT, and the delivery note shows an excess of 0.2 MT, the engine flags the discrepancy and calculates the exact financial impact:

Financial Impact=Excess Quantity×Standard Rate Financial Impact=0.2 MT×70,000 Rs/MT=Rs 14,000

By keeping the math deterministic, we guarantee that Setu's flagged leakages are always mathematically sound, not AI approximations.

Challenges we ran into

The biggest challenge was dealing with the unpredictability of AI extraction. Early on, we fed the AI poorly scanned, handwritten delivery notes, and it would occasionally hallucinate quantities—reading a "5" as an "8." We couldn't ship a product that forced users to trust potentially hallucinated financial numbers. To solve this, we built a confidence-scoring mechanism. Now, if the AI isn't highly confident in a parsed number (due to bad handwriting or smudges), Setu refuses to push it into the Reconciliation Engine. Instead, it flags that specific line item for human review. It forced us to design a "human-in-the-loop" architecture rather than a fully autonomous one.

Accomplishments that we're proud of

We are incredibly proud of the architecture we designed. It’s easy to build an AI wrapper, but it's much harder to build a system where AI handles the messy language parsing while traditional code handles the strict financial math. We actually solved the hallucination problem for financial use cases. We're also proud that we took the time to understand the construction domain deeply enough to build something that solves a real, costly pain point rather than a hypothetical one.

What we learned

We learned that the right tool for the job isn't always the newest one. Our first instinct was to prompt the AI to calculate the leakage directly. It failed. We learned that LLMs are incredible at language parsing (reading documents) but terrible at strict arithmetic. Separating the probabilistic AI layer from the deterministic math layer was the "aha!" moment of the project. Beyond the tech, we learned how BOQs work, what a delivery note actually looks like on a dusty job site, and why a 1-2% billing leakage can mean crores of rupees lost at scale.

What's next for Setu

Our immediate next steps are direct ERP integrations (like SAP/Oracle) for automated background running, and a lightweight mobile app for site engineers to scan delivery notes the moment a truck arrives.

Next, we are expanding across the entire material lifecycle to close the loop:

BOQ-to-Procurement: Moving upstream to verify Purchase Orders against BOQs before materials are ordered, stopping over-ordering and inflated rates at the source.
Site Receiving & Wastage: Tracking actual physical material consumption against paid quantities to catch on-site theft or excessive wastage in real-time.