Inspiration

Every construction project runs on the same broken loop: a purchase order gets issued, materials show up (or don't, or partially do), an invoice arrives, and someone is supposed to check that all three agree before money moves. In practice, that check is done by hand, under time pressure, across documents that never format the same information the same way. We kept coming back to one line that captures it perfectly — "the bitterness of poor quality remains long after the sweetness of low price is forgotten." Procurement isn't about spending less, it's about buying right — and right now, nobody has the tooling to catch it when they're not.

What it does

ProcureIQ is an AI procurement analyst that automatically performs three-way matching across Purchase Orders, Delivery Records, and Invoices. It extracts structured line items from each document, cross-references them even when vendors describe the same material differently, and flags real discrepancies — not routine noise. Every flag is explained in plain language and grounded in the actual governing contract clause via RAG, so it's defensible, not a black-box guess. The system also builds a running vendor risk score from delivery delays, quantity mismatches, price variance, and discrepancy history, and can draft a ready-to-send follow-up query when something needs a vendor's attention.

How we built it

The frontend is a React + Tailwind dashboard showing matched line items, flagged discrepancies, and vendor risk scores. The backend runs on Node.js + Express, handling document ingestion through an async upload queue. Document extraction and matching reasoning run on Groq-hosted Llama models, with a vector store (LanceDB/Chroma) holding embedded contract clauses for RAG-based retrieval whenever a discrepancy needs explaining. A dedicated matching engine sits between raw extraction and the LLM layer, combining semantic similarity for inconsistent item descriptions with rule-based tolerance thresholds so the system distinguishes routine variance from genuine risk before anything reaches the model.

Challenges we ran into

The hardest problem wasn't calling an LLM — it was making the matching trustworthy. The same material shows up worded differently across every document a vendor sends, so naive string matching fails constantly; we had to combine embedding similarity with structured field comparison instead. We also had to resist the easy path of flagging every numeric difference — a 2% quantity variance from normal wastage isn't the same as a 15% price jump with no contract backing, and building that distinction meant encoding real tolerance-band logic rather than letting the model decide case by case.

Accomplishments that we're proud of

We designed a system where every discrepancy flag is explainable and traceable to a specific contract clause, rather than an LLM asserting something is wrong with no receipts. We also moved vendor evaluation from a one-off gut check to a running, evidence-based score — which is the kind of institutional memory construction procurement almost never has.

What we learned

We went deep on how construction procurement actually works — bids, contracts, POs, delivery records, invoices, and the three-way match discipline that's supposed to tie them together — and learned that the real technical challenge in domain-specific AI tools isn't the model call, it's the layer of domain logic that decides when the model should be trusted and when a rule should override it.

What's next for ProcureIQ

Real vendor and ERP integrations (so documents flow in automatically rather than being uploaded manually), expanding beyond three document types to include bid comparisons and change orders, and refining the vendor risk model with real historical project data instead of synthetic examples.

Built With

Share this project:

Updates

Submission history