Skip to content
SKSuraj Kumar

Document processing

Document Intelligence & Human Review

Turns high-volume business documents into checked, structured data — and routes only the uncertain fields to a human reviewer.

  • AI system
  • AI
  • Document processing
  • B2B
  • Next.js
Role
Sole engineer. Product definition, frontend architecture, extraction service integration, validation rules and the review tooling.
Work type
Private client project
Timeline
10 weeks build effort · 2024
Status
Case study published
Client
Private client work

Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.

Interface built in code for this case study — not a client screen capture.

01Business problem

What was actually going wrong

Businesses still retype invoices, contracts, receipts and forms into their systems by hand, and the errors that slip through are found weeks later by someone reconciling numbers.

Who feels it

  • Finance and operations teams processing supplier documents
  • Back-office staff doing manual data entry
  • Reviewers and approvers who sign off on extracted values
  • Engineering teams asked to "just parse the PDFs"

Every operations team that receives documents from outside the company ends up with the same workflow: a shared inbox, a folder of PDFs, and a person who opens each one and types values into an ERP, a spreadsheet or an internal tool. The work is slow, it does not scale with volume, and it produces inconsistencies that are expensive to unwind — a vendor name spelled three ways, a tax field left blank, a total that does not match its line items.

The usual response is to buy an OCR tool. That solves the easy half of the problem. Raw text extraction leaves the hard half untouched: deciding which of the extracted values can be trusted, what to do when a document type is unfamiliar, how a reviewer sees the original document next to what the machine read, and how the business proves later why a value was accepted.

The gap is not recognition accuracy. It is the absence of a workflow around uncertainty. Without one, teams either trust everything the model returns, or check everything by hand and lose the benefit entirely.

02Product overview

What got built

A document processing application that combines classification, field and table extraction, rule-based validation, confidence scoring and a keyboard-driven human review queue, with a full audit trail behind every accepted value.

Engineering notes

  • Field-level confidence and page provenance modelled as a typed union
  • Deterministic validation separated from model output
  • Reducer-driven review session with append-only corrections
  • Overlay document viewer built from normalized coordinates

Documents enter through upload or a watched folder and are classified before extraction, so an invoice, a purchase order and a delivery note each get the field set they are supposed to have. Extraction returns values with a confidence score and a location on the page, which is what makes review possible: the reviewer sees the highlighted region in the original document beside the value the system read.

Validation runs after extraction and before review. Rules are ordinary code, not model output — line items must sum to the subtotal within tolerance, dates must be plausible, a tax identifier must match a known format, a required field cannot be empty. Failures downgrade the document into the review queue with the specific issue attached, rather than silently passing.

Review is designed for volume. Fields are ordered by how uncertain they are, the reviewer works with the keyboard, and accepting or correcting a value records who did it and when. Only documents that clear validation and review get exported, and every export carries the processing history that produced it.

03Key features

What the software does, feature by feature

10 capabilities, of which 3 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.

  • 01

    Multi-format intake

    PDF, scanned images and email attachments enter one queue with per-document processing state, so nothing sits in a folder unaccounted for.

  • 02

    Document classificationmodel-backed

    Each document is typed before extraction — invoice, purchase order, receipt, contract, form — which determines the schema applied to it.

  • 03

    Field extraction with provenancemodel-backed

    Every extracted value carries a confidence score, the page it came from and the region it was read from, so it can be shown in context.

  • 04

    Table and line-item extractionmodel-backed

    Repeating rows are extracted as structured tables with per-cell confidence, handling the multi-page tables that break naive parsers.

  • 05

    Rule-based validation

    Arithmetic, format, date-range and required-field rules run as deterministic code after extraction and attach specific issues to specific fields.

  • 06

    Confidence thresholds

    Per-field thresholds decide what passes automatically and what a person must see, and they are configurable per document type.

  • 07

    Side-by-side review

    The original document is shown with the extracted region highlighted next to the value, so a reviewer verifies rather than re-reads.

  • 08

    Keyboard review queue

    Fields are ordered by uncertainty and moved through with the keyboard — accept, correct, skip — because this screen is used for hours.

  • 09

    Audit history

    Classification, extraction, validation, every correction and the final export are recorded as an append-only trail per document.

  • 10

    Structured export

    Cleared documents leave as typed JSON or CSV against a stable schema, so downstream systems are not exposed to model output shape.

04User flow

How a person moves through it

The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.

  1. 01OperationsUploads a batch of supplier documents or drops them into the watched folder.
  2. 02SystemClassifies each document, applies the matching field schema and begins extraction.
  3. 03SystemScores every field, runs validation rules and marks documents as cleared or held for review.
  4. 04ReviewerOpens the review queue, which lists held documents with the reason each one is held.
  5. 05ReviewerWorks through flagged fields against the highlighted document region, correcting what is wrong.
  6. 06ReviewerApproves the document, which closes the review and stamps the audit trail.
  7. 07SystemExports the structured record and keeps the processing history available for later inspection.

05Architecture

How it is put together

The processing path first, then the layers it runs on, then the constraints that shaped both.

Path through the system

6 stages

  1. 01

    Upload

    Batch intake, deduplication by content hash, per-document state record created.

  2. 02

    Classify

    Document type determined, field schema selected, unknown types routed to triage.

  3. 03

    Extract

    Fields and tables returned with confidence and page coordinates.

  4. 04

    Validate

    Deterministic rules attach issues; thresholds decide auto-clear or hold.

  5. 05

    Review

    Uncertain fields queued for a human, corrections recorded against the original.

  6. 06

    Export

    Typed record emitted with its processing history attached.

Layers

Interface
Document queue with processing stateSplit-pane review workspaceField inspector with confidence displayTable editor for line itemsAudit timeline per document
Application state
Typed extraction result modelReview session reducer (accept / correct / skip)Optimistic corrections with rollbackQueue pagination and filter state
Services
Classification callExtraction call with schema parameterValidation rule runner (deterministic, local)Export serializer
Records
Document + version storeField-level correction logAppend-only audit eventsPer-type threshold configuration

Why it is shaped this way

  • The frontend never trusts extraction output shape. Responses are parsed into a typed model at the boundary, and anything unexpected marks the document for triage instead of rendering a broken field.
  • Validation is intentionally not a model. Arithmetic and format rules are cheap, deterministic and explainable, which matters when a reviewer asks why a document was held.
  • Review state is a reducer rather than scattered component state, because a review session has real invariants: a field cannot be both accepted and flagged, and a document cannot be approved with open issues.

06Technical decisions

The choices that mattered, and what each one cost

Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.

01

Model extracted fields as a typed union with confidence and provenance, not a flat key-value bag.

Why

The interface needs to answer three questions per field: what was read, how sure the system is, and where it came from. A flat object cannot express the third, and provenance is what makes side-by-side review possible.

Trade-off

Every consumer of a field has to handle the union, which is more code than reading a string. The payoff is that an unreviewed value can never be rendered as if it were confirmed.

02

Run validation on the client as pure functions over the parsed result.

Why

Rules are arithmetic and format checks. Keeping them local makes the reviewer experience immediate — correcting a line item re-runs the sum check as you type — and keeps rule logic readable and unit-testable.

Trade-off

Rules would need to be duplicated or shared as a package once a server pipeline also enforces them. The shape was kept dependency-free so it can be lifted out unchanged.

03

Order the review queue by uncertainty rather than document order.

Why

Reviewer time is the scarce resource. Sorting fields by confidence and validation severity means the highest-risk values are seen first, and a reviewer can stop when the remaining fields are above threshold.

Trade-off

Reviewers lose the natural reading order of the document, so the interface has to work harder to keep them oriented — hence the persistent document pane with the active region highlighted.

04

Keep corrections as an append-only log instead of mutating extracted values.

Why

The business question is not only what the value is, but who changed it and from what. An append-only log answers both and makes the audit timeline a read of existing data rather than a separate feature.

Trade-off

Reading a current value means folding the log, so the model exposes a resolved view to the interface and keeps the folding in one place.

05

Treat unknown document types as a first-class state.

Why

Real intake always contains something the classifier has not seen. Routing those to a triage state keeps them visible instead of forcing them through the wrong schema and producing confidently wrong fields.

Trade-off

Adds a queue someone has to manage. That is the honest cost of not silently mis-extracting.

07Challenges

What was genuinely difficult

Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.

01

Showing a reviewer where a value came from, without shipping a heavyweight PDF viewer.

Approach

The extraction response carries normalized page coordinates. The review pane renders a page image with absolutely positioned overlay regions, and the active field scrolls its region into view. Coordinates are normalized at the parse boundary so the overlay never has to know the source resolution.

Outcome

Verification became a glance instead of a hunt, and the viewer stayed a few hundred lines of ordinary layout code.

02

Multi-page tables where a line-item block continues across a page break.

Approach

Rows are keyed by their position within the logical table rather than the page, and continuation is detected by column geometry and header repetition. The editor treats the table as one object with a page marker per row so a reviewer still knows where a row physically sits.

Outcome

Line items reconcile against the subtotal across page breaks, which is where naive row-per-page parsing produces silent shortfalls.

03

Keeping the review screen fast with hundreds of fields and overlay regions in the DOM.

Approach

Only the active page renders overlays, the field list virtualizes beyond a threshold, and corrections update through the reducer rather than re-parsing the extraction result. Derived values are memoized against the resolved field map.

Outcome

Keyboard-driven review stays responsive on large documents, which is the difference between a tool people use and one they avoid.

08Business value

What it changes for the business

Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.

Operational effect

  • Removes the retyping step for documents the system is confident about, and narrows human attention to the fields that are actually uncertain.
  • Produces consistent field values against one schema per document type, instead of whatever each person typed.
  • Makes uncertainty visible — a reviewer can see which values were low-confidence rather than discovering it during reconciliation.
  • Creates a defensible processing history for every exported record, which matters for audit and for disputes with suppliers.
  • Gives an operations lead a queue they can staff and measure, rather than an inbox they can only hope is empty.

What would change at scale

  • Move validation into a shared package so the same rules run in the pipeline and in the reviewer interface, with the interface treating server results as authoritative.
  • Process extraction asynchronously with a job record per document and push state to the queue, so a large batch does not depend on a browser session staying open.
  • Version field schemas per document type, so changing a schema does not retroactively invalidate documents already exported against the old one.
  • Feed accepted corrections back as an evaluation set to measure whether extraction quality is drifting per document type, rather than trusting a single accuracy figure.

09Interface

The screens where the work happens

Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.

Review workspace

Original document with the active extracted region highlighted, field list ordered by confidence, and validation issues attached to the specific field that failed.

Processing queue

Every document with its type, stage, confidence band and hold reason — the screen an operations lead works from.

Line-item table

Extracted table with per-cell confidence and a live subtotal check that re-runs as a reviewer corrects a row.

Audit timeline

Classification, extraction, each correction with its author, approval and export, as an append-only trail.

The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.

10Technologies

What it is built with

Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.

Frontend
  • Next.js App Router
  • TypeScript
  • Tailwind CSS
  • React Server Components
AI layer
  • LLM extraction APIs
  • Structured output schemas
  • Document classification
  • Confidence scoring
Application
  • Typed API boundary
  • Reducer-based review session
  • Deterministic validation rules
  • Append-only correction log
Data
  • PostgreSQL
  • Object storage for source documents
  • Audit event log

11Technical preview

Structure, models and annotated excerpts

There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.

Technical preview

Implementation detail for this build

Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.

A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.

Inside this section

  • Module and folder structure for the build
  • Data models and the interface contracts between layers
  • 3 annotated implementation excerpts
  • Design notes covering the decisions the excerpts imply
  • The same keyword opens every case study on the site

For private client work, contact me for a walkthrough.

Next step

Need something along these lines?

Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.

Email
surajk86808@gmail.com
Based in
Bengaluru, India
Working hours
IST (UTC+5:30)
Availability
Taking new engagements