You are going to build me a browser-based invoice diagnostic tool. Read this whole message before you respond.
What to build: a single self-contained HTML file that runs entirely in a web browser. No server, no Python, no installation, no downloads. All PDF text extraction happens in the browser using PDF.js loaded from a CDN. I open the file by double-clicking it and it just works.
How to respond: give me one complete, working HTML file, not a partial draft or an outline. Put all HTML, CSS, and JavaScript in that single file. Don't stop partway to ask what to build next; build the whole thing, then tell me what to try. If a design choice is genuinely ambiguous, make a reasonable choice and note it rather than pausing.
What it does: I upload two PDFs, an invoice and a contract or rate schedule. The tool extracts the text from both, matches each billed line against the contract rate for that item, flags every discrepancy with a severity level and a dollar impact, recalculates what the invoice should total, and shows a line-by-line comparison table.
What it needs to handle: real invoices are not all laid out the same way, so the parser should try to handle more than one shape. Grouped invoices have a code-and-description header (like "20101 - Journeyman Electrician") with individual staff or work-order rows beneath it and a subtotal. Flat invoices put one line item per row (code, description, quantity, rate, amount). Materials or unit-rate lines bill a cost basis times a markup multiplier (for example, $4,880 of material cost at a 1.10 markup). The contract side is a rate card keyed by billing code, which may be numeric (10015) or alphanumeric (LAB-01).
Errors it should catch: rate drift (right service, wrong unit price), materials-markup drift (billed markup higher than the contract markup), math that doesn't foot, a percentage fee calculated on an inflated base so the error compounds, and a printed or header total that doesn't match the summed lines. For each flag, show the billed figure, the correct figure, and the dollar difference.
Before you write any code, ask me these six questions. Output the questions only, no preamble. Tell me I can answer all of them, some of them, or skip them entirely and you will build a sensible generic version I can refine later.
- What is your industry or service type? A) Testing, inspection, or materials lab B) Professional services or consulting C) Construction or subcontracting D) Staffing or managed services
- How are rates structured in your contracts? A) A negotiated rate exhibit attached to each PO or work order overrides the standard price list B) A master rate card applies to all projects; individual contracts reference it but don't change it C) Each engagement has fully custom rates with no standard fallback D) Hybrid, some items negotiated per contract, everything else defaults to the standard schedule
- What billing errors do you most need to catch? (Select all that apply) A) Rate drift, right service, wrong unit price B) Scope errors, services billed that the client didn't authorize C) Math errors, subtotals or totals that don't add up D) Change order errors, work billed against a change order that wasn't approved, exceeds the approved amount, or was billed at the wrong rate
- Do you bill materials, equipment, or other pass-through costs with a markup? A) Yes, materials or equipment billed at cost plus a defined markup or multiplier B) Yes, but markup rules vary by item C) No, labor and services only
- How are line items identified on your invoices? A) Numeric billing codes B) Alphanumeric codes (LAB-01, INSP-HR) C) Text descriptions only, no codes D) Mixed
- Who will primarily use this tool? A) Project managers reviewing their own invoices before submission B) A centralized billing or admin team C) Finance or AP staff reviewing vendor invoices D) Multiple roles
After I answer (or skip), ask whether I can paste a sample invoice and contract, or their text, so you can tune the parser to how my documents actually lay out their line items and rates. Tell me it's fine to skip this too.
Build requirements: Include a "Load Sample Data" button that runs a realistic built-in example, so the tool always has something to show even before I upload anything. When an uploaded file doesn't match the expected layout, don't fail silently: show the raw extracted text and tell me to paste a sample so the parser can be tuned. Prefer a forgiving parser that extracts what it can from an unfamiliar layout and clearly marks what it couldn't read, rather than matching nothing. State clearly in the interface that the tool reads digital PDFs with a real text layer and cannot read scanned image-only documents, which would need OCR in a fuller build.
