AI Answer Library

Can a knowledge base handle scanned documents and complex tables?

Short answer

Yes, but only if you handle each document type separately — dumping everything into one pipeline does not work. Scans must go through OCR first, and complex layouts additionally need layout analysis to recover the correct reading order. Tables with merged cells or multi-level headers will almost certainly be mangled by ordinary text chunking; they need to be extracted as structured data before ingestion. The real cost sits in the preprocessing pipeline and human spot-checks, not in the model. When the source documents are poor, cleaning them up beats swapping models.

Key points

  • 01Classify first, then process. Digital PDFs, clean scans, poor scans, complex tables and engineering drawings need five different paths; one pipeline for all guarantees that one category gets sacrificed.
  • 02Tables concentrate the errors. Merged cells, multi-level headers and tables continuing across pages lose their row-column relationships once flattened to text, and the model sees a string of misaligned numbers.
  • 03Reading order fails more often than character recognition. Without layout analysis, two-column pages, headers, footers and margin notes come out of OCR in scrambled order, and chunking then destroys the meaning.
  • 04Parsing output must be spot-checked, and by the business side. An engineer cannot tell which quarter a number belongs to; the person who wrote the report can, instantly.
  • 05Some documents are not worth parsing. Low-quality faxes, heavy handwriting and stamps covering key fields are often cheaper to key in by hand than to chase with pipeline tuning.

A workable approach per document type

The table is organised around ingestion into an enterprise knowledge base. The difficulty column is relative, not absolute — a 300 dpi contract scan and a skewed phone photo of the same page are worlds apart. In practice, count what proportion of your corpus falls into each type, then do the top one or two properly instead of chasing full coverage from day one.

Document typeMain difficultyWhat worksEffort
Digital PDF, Word, web pagesRecognition is a non-issue; chunk granularity is the questionChunk along heading hierarchy and keep the section path as metadataLow — off-the-shelf tooling suffices
Clean scans (300 dpi and up, printed text)Character accuracy is fine; reading order must be reconstructedOCR plus layout analysis, with columns, headers and footers handled separatelyMedium — needs sampled correction
Poor scans (handwriting, stamps, skewed photos)High and unstable error rate, failing unpredictablyExtract key fields only, force human review, and do not ingest full textHigh — manual entry is often cheaper
Complex tables (merged cells, multi-level headers, page breaks)Flattening to text destroys row-column mapping and misaligns every numberRun dedicated table extraction into structured storage, and answer by querying rather than retrievingHigh, and every table needs verification
Drawings, flowcharts, diagramsMeaning lives in the graphical relationships and is mostly lost in textHave a multimodal model produce a structured description for ingestion while keeping the original for human inspectionHigh, with accuracy resting on human confirmation

Why tables fail more than anything else

Ordinary text chunking assumes adjacent characters belong to the same sentence, but a table's meaning is two-dimensional: a number means what it means because of both its row label and its column label. Flatten it into lines and that mapping is gone. The model then sees isolated numbers, guesses labels from whatever words are nearest, and confidently reports the South China figure when asked about East China in Q3 2025. Continuation tables are worse: the second page usually carries no header, so after flattening there is no way to tell which column a number belongs to. The workable approach is to extract tables separately into structured storage — a database table, or JSON carrying the full header — and answer with a structured query instead of vector retrieval. The fallback is to generate a natural-language summary per table with the context spelled out, trading precision for coverage.

The verification round you cannot skip

Once the pipeline has run, sample a batch of documents and put the original page next to the parsed output for a business colleague to mark up. This step gets skipped because it looks unglamorous, yet it is the only way systematic errors surface — every stamped contract losing a digit from the amount, every continuation table attributed to the wrong parent. Stratify the sample by document type with a few dozen per type rather than sampling uniformly from the whole corpus, or the small-but-critical categories will never be drawn. Classify each error found: recognition, ordering, or chunking? The three have completely different fixes. Finally, freeze the annotated batch into a regression set and replay it after every pipeline change, otherwise you cannot tell whether this change fixed one problem while breaking two others.

Where this applies

When this answer does not hold

  • No recognition accuracy figures are given here. The same pipeline performs an order of magnitude differently on a 300 dpi printed contract versus a phone photo of a handwritten form, so any percentage detached from a sample is meaningless. Test on your own documents.
  • For documents containing amounts, dosages or engineering parameters, keep a human review step regardless of parsing quality. A parsing error there costs far more than the reviewer's time.
  • If the corpus itself contains conflicting versions, large amounts of stale content or no permission boundaries, perfect parsing still yields wrong answers. That is a content governance problem, not a technical one.
  • Scans and images routinely contain personal or commercially sensitive information, so the parsing pipeline — especially any step calling an external service — needs its own data-residency review.

People also ask

  • Can scanned PDFs be turned into a knowledge base?
  • How do tables with merged cells get into a knowledge base?
  • Which document formats does a knowledge base support?
  • What do I do when tables inside PDFs are parsed incorrectly?
  • Can AI read handwritten or stamped documents?
Written by: YGG Technology Solutions TeamPublished: 2026-08-01Last reviewed: 2026-08-01