VeriBook

• 

  Landing Page

• 

  The Inbox: every invoice is checked against the order and receipt; anything unusual waits for a person, with the exact reason.

• 

  A clean three-way match is approved and paid on its own, with every check and the AI reviewer's role on record.

• 

  Fraud hold: the vendor's bank account changed, so nothing is paid until a phone check and a second person sign off.

• 

  A blocked overcharge: billed above the agreed price, with the exact figures that do not match.

• 

  Audit trail: every decision is hash-chained, and one click re-hashes the whole chain to show it is untouched.

• 

  Decision lab: 42 of 42 policy cases decided as the written spec says, 0 wrongly paid.

• 

  Quality page: honest results on real invoices, including the targets we missed.

• 

  Reads a phone photo of an invoice: the page is flattened, read by OCR, and every field is tagged with how it was read.

The one-line version

Invoices go in. A payment decision comes out. The AI can hold an invoice. It can never approve one.

🏆 Winner, Autonomous Office of the CFO track, Syndicate by Maximor 2026.

Inspiration

Before a company pays a vendor, someone checks the invoice against the purchase order and the delivery receipt. That is the "three-way match", and most companies still do it by hand. Duplicates slip through. Prices get billed above what was agreed. And a vendor's "updated" bank account can be wire fraud in disguise.

We did not want a rules engine that silently approves everything, or a chatbot that invents a reason when you ask "why". We wanted a system that does the matching for real, escalates only what needs judgement, and can defend every decision to an auditor months later.

What it does

• Reads what it is given. PDF, scan, phone photo, Word or Excel. OpenCV flattens the page, layout rules read the fields, and the AI fills only gaps with values printed on the page.
• Three-way matches every line to the purchase order and the goods receipt: price, quantity, units, tax, dates.
• Rules decide the money. A rules engine settles every invoice first. An AI investigator and a second model from a different family can only make the outcome stricter: hold, never approve.
• Fraud guard. A changed vendor bank account freezes payment until someone phones the vendor on a number from your own records and a second person signs off.
• Explains itself. Every verdict says what did not match, with the figures, in plain words.
• Tamper-evident trail. Every decision is hash-chained. The Audit page re-hashes the whole chain and shows it intact.

How we built it

Next.js and TypeScript for the app and 40+ API routes, a Python document reader (Docling, RapidOCR, OpenCV), Postgres with a double-entry ledger and exact-decimal money, Groq-hosted open models (gpt-oss-120b investigator, Qwen verifier), line matching with similarity scoring plus the Hungarian assignment algorithm, and GitHub Actions that run the extraction benchmark, the document scorer and a decision lab on every push.

Proof, with its limits

• Decision lab: 42 of 42 policy cases decided as the written spec says, 0 wrongly paid, 0 silent errors. It found 3 real bugs on its first runs, all fixed. The cases are ones we wrote, and 11 were edited after a run disagreed; each is marked.
• Reading documents: 346 of 351 fields right on 39 generated documents (scans, photos, screenshots, PDF, Word, Excel); the 5 wrong ones were flagged for a person, 0 silent. Latin script only, no handwriting.
• Damaged invoices: 0 of 115 damaged documents let through, 0 of 125 ordinary ones wrongly held (generated by us, so it tests the faults we thought of).
• 870 automated tests, and concurrency tests: an approve and a reject racing on one invoice leave exactly one winner, and paying a bill three times at once pays once.

My contribution

I'm Devang Mishra. I built VeriBook end to end except the first version of the front end, which my teammate Ankit Singh built.

• Designed the rules-first decision engine and the policy that the AI can hold an invoice but never approve one.
• Three-way line matching (similarity scoring plus the Hungarian assignment algorithm), price and quantity tolerance zones, and the exception codes.
• The AI investigator and the second-model verifier, the hash-chained audit trail, and the Postgres double-entry ledger.
• The document reader (OpenCV, OCR, layout rules) and the evaluation lab and CI gates behind the numbers above.
• I wrote the specs and the tests, directed AI coding agents for much of the implementation, and reviewed and measured every result.

Challenges

The first version of our benchmark was too easy. Adding ordinary invoice layouts showed the vendor-name reader picked the wrong vendor on 44 of 125 invoices with no warning. We fixed it, and kept the harder benchmark.

What we learned

Put the AI where language is messy and the rules where money moves. Measure before you trust. Publish the limits next to the numbers.

What's next

Handwriting and non-Latin scripts, real vendor data instead of generated documents, and approval chains that follow a company's own policy.

Try it

Live demo: https://veribook.duckdns.org (open any "Start here" card in the Inbox).

Code: https://github.com/devangmishra1424/open-ledger

Original hackathon materials: https://drive.google.com/drive/folders/1Fwi7LcBN2blx8D7q5ghR7kNAyj8DSVzz?usp=sharing

Built With

• docling
• github-actions
• groq
• llm
• next.js
• ocr
• opencv
• postgresql
• python
• react
• supabase
• typescript