For a trading business receiving over a hundred invoices every working day, manual data entry is not a minor operational inefficiency — it is a structural bottleneck that compounds across every downstream function: accounting accuracy, cash flow visibility, supplier payment timing, and reconciliation overhead.

• ⏱ 80–120 invoices daily, each requiring 8–12 minutes of manual data entry — vendor name, invoice number, date, line items, GST breakdown. Full-time cost: 2 operators doing nothing else, all day, every day.
• 📄 Invoice formats were completely inconsistent — 35+ supplier templates spanning native PDFs, scanned paper, photographed invoices (on phones), and Excel-exported PDFs. No "standard" format to build a template parser around.
• ❌ Manual entry error rate: ~3–4% (3–4 errors per 100 invoices). In a trading business, a miskeyed unit price or quantity causes purchase order mismatches that take hours to reconcile downstream.
• 📉 3–4 day average delay between invoice receipt and accounting entry — creating cash flow visibility gaps and occasional late payment penalties from suppliers who had terms tied to receipt confirmation.
• ♻️ No duplicate detection — the same invoice was occasionally entered twice when forwarded across multiple email chains, creating phantom liabilities in the accounts payable balance sheet.

KLYX proposed a multi-stage AI pipeline: pre-processing → OCR → LLM extraction → validation → accounting export. The key architectural insight was NOT to build a template-based parser (fragile — breaks every time a supplier changes their format) but an LLM-driven one that reads invoices like a human reads them: by understanding context and semantics, not field positions.

The pipeline treats each invoice as a document to be understood, not a form to be matched against a template. A rule-based parser would need to be hand-coded for each of the 35+ supplier formats and would break silently every time one changed. An LLM-based parser generalises — it understands that "Total Amount", "Net Payable", and "Amount Due" are the same concept regardless of where they appear on the page.

Each stage in the pipeline has a clearly defined responsibility. Pre-processing normalises the raw document into clean text. Extraction converts that text into structured JSON. Validation catches the errors extraction misses. Export pushes clean, approved data into the accounting system with zero re-entry.

1. Audit: Collected 200 sample invoices covering the full range of supplier formats. Classified by type: native PDF (40%), scanned paper (30%), photographed invoice (20%), Excel-exported PDF (10%). Each type needed different pre-processing — a single ingestion approach would have degraded extraction quality across the board.
2. Pre-processing pipeline: Native PDFs → PyPDF2 text extraction. Scanned/photographed → AWS Textract OCR (best results for mixed Hindi/English content common in Indian supplier invoices). Excel PDFs → camelot table extraction. Output: normalised text per invoice, regardless of source format.
3. LLM extraction layer (Claude API, Haiku model for cost-efficiency at volume): Structured prompt requesting JSON output — {vendor_name, gstin, invoice_number, invoice_date, due_date, line_items: [{description, hsn_code, qty, unit, rate, amount}], subtotal, gst_breakdowns, total}. Few-shot examples per invoice type included in the prompt to anchor output format.
4. Validation layer: Checks extracted subtotal against sum of line items (catches LLM arithmetic slips), verifies CGST+SGST or IGST amounts match stated rates, flags invoices where the extracted total deviates more than 1% from the calculated total for human review. This is the safety net — not a nice-to-have.
5. Purchase order matching: Extracted invoice numbers and vendor GSTINs compared against open POs in the accounting system via API. Matched invoices auto-populate PO references; unmatched ones go to a review queue with suggested matches ranked by confidence score.
6. Duplicate detection: SHA-256 hash of {vendor_gstin + invoice_number + total_amount} checked against the processed invoice database. Duplicate detected → rejected and flagged before any accounting entry is created.
7. Accounting system export: Approved invoices pushed via REST API as draft bill entries with all line items, GST breakdown, and PO reference pre-filled. Operator verifies and approves in 1 click — no re-entry required anywhere in the workflow.
8. Human-in-the-loop review dashboard (Next.js): Shows the exceptions queue — invoices flagged for validation errors, PO mismatches, or low LLM confidence scores. Target: operators handle under 15% of total invoice volume via this dashboard. Everything else flows through automatically.

• 8 duplicate invoices caught in the first 30 days — prevented approximately ₹2.3L in phantom liabilities from entering the balance sheet.
• The operations team went from 8 hours/day of data entry to 1–2 hours reviewing the exceptions dashboard — an 80%+ productivity gain with no headcount reduction required.
• Monthly GST reconciliation became significantly easier with clean, structured invoice data already in the accounting system — no end-of-month data cleaning sprint.

• Template-based invoice parsing breaks constantly. Every new supplier, every format change, every scanned document breaks a rule-based parser. LLM-based parsing generalises because it reads context like a human — "Total Amount", "Net Payable", and "Amount Due" all mean the same thing, regardless of where they appear on the page.
• Validation is more important than extraction accuracy. The LLM gets extraction right approximately 95% of the time. Catching the remaining 5% with arithmetic validation (do line items sum to the stated total?) is what prevents accounting errors. Build the safety net before trusting any auto-approval.
• Keep humans in the loop for exceptions, not for everything. 100% automation is not the goal — 88% automation with a tight exception-handling workflow is. Operators go from 8 hours of data entry to 1–2 hours of exception review per day. That's still an 80%+ productivity gain, and it's sustainable because humans only touch the genuinely ambiguous cases.