Project Story

Inspiration

When we first read the Kaya Hackathon problem statement, one theme immediately stood out: construction has become much better at tracking materials, but not at verifying them before payment. That distinction intrigued us.

As we dug deeper, we realized that while many existing solutions answer questions like "Where is the truck?" or "Has the shipment arrived?", very few answer the question that finance teams ultimately care about:

"Should we actually pay this invoice?"

To validate whether this was a real problem and not just an assumption, we spoke with industry professionals, including supply chain leaders, procurement professionals, and venture capitalists with experience in construction technology. Their feedback was surprisingly consistent. Material reconciliation and invoice settlement remain highly manual, relying on spreadsheets, emails, PDFs, and WhatsApp conversations. They encouraged us to explore this problem further, which ultimately led to the idea behind Reckon.

How We Built It

We designed Reckon around a deterministic reconciliation engine supported by AI-powered document understanding.

Our pipeline starts with Vision Language Models to understand scanned documents and photographs. Layout-aware extraction converts those documents into structured data. Entity resolution and fuzzy matching then identify which Purchase Orders, Delivery Challans, Weighbridge Slips, GRNs, Contracts, and Invoices belong together, even when they don't share common identifiers.

Finally, a deterministic reconciliation engine compares quantities, weights, material grades, and unit rates to either approve payment or generate an exception report with the exact financial impact.

On top of this shared engine, we built three AI agents:

Bid Leveler for comparing contractor quotations before contract award.
Contract Sentinel for validating invoices against signed contracts.
PO-to-Payment Reconciliation for verifying deliveries before payment approval.

Challenges

The biggest challenge wasn't building the AI itself—it was choosing the right technology for each stage of the pipeline.

Initially, we experimented with several different approaches for document parsing, OCR, embeddings, entity resolution, and reconciliation. Some approaches worked well for clean PDFs but failed on scanned documents. Others extracted information accurately but struggled to associate related documents together.

Much of our development process became an exercise in trial and error. We evaluated different models, tested multiple document-processing pipelines, and iteratively refined the architecture until we arrived at a workflow that balanced accuracy, explainability, and practical feasibility.

Another challenge was keeping financial decisions deterministic. While AI is excellent at understanding unstructured documents, we deliberately avoided letting an LLM make payment decisions. Instead, AI extracts information, while a deterministic rule engine performs all reconciliation and financial calculations, making every decision transparent and auditable.

What We Learned

Building Reckon taught us that solving enterprise problems is often less about building a larger model and more about designing the right workflow around it.

We learned that AI performs best when paired with deterministic business logic, especially in financial applications where explainability and trust are essential. We also gained a much deeper appreciation for the complexity of construction procurement and the importance of validating ideas through conversations with domain experts before writing a single line of code.

Ultimately, Reckon reflects a simple philosophy: