Data Extraction

What is Data Extraction?

Data extraction retrieves selected information from a source for a defined downstream purpose. A person can extract values manually, a query can retrieve fields from a database or API, a parser can read structured rows, or software can propose fields from semi-structured documents.

Sources vary in structure and reliability. Databases and APIs can expose named fields. CSV and spreadsheet files provide rows and columns but still require schema interpretation. PDFs and other documents can contain layout, repeated labels, footnotes, scans, or ambiguous dates that make extraction more difficult.

The output should preserve enough source context to be checked. A value without its document, period, currency, unit, account, counterparty, or line reference can be difficult to validate and easy to misuse. Extraction is an input step, not proof that the source or retrieved value is correct.

Extraction versus parsing

Parsing interprets the structure or syntax of a source. Extraction selects the information needed for a purpose. A CSV parser may separate every row and field, while extraction chooses the date, amount, description, or balance fields needed downstream.

A parser can work correctly while the selected fields are still semantically wrong for the intended record.

Extraction versus import

Extraction retrieves or proposes data. Import writes accepted data into a destination according to that destination's rules.

Keeping the steps separate creates a review boundary. A person can reject, edit, reroute, or skip an extracted item before it becomes a canonical record.

Extraction versus transformation

Transformation changes data into another representation, such as normalizing a date, mapping a category, converting units, or combining fields. Extraction can feed transformation, but the operations should remain identifiable.

Silent transformation can hide assumptions. The downstream user should know which value came from the source and which value was derived or changed.

Common source patterns

• APIs and databases

  Structured fields with explicit query and access rules, but still subject to source quality and versioning.

• CSV and spreadsheets

  Tabular data that requires schema, type, locale, and header validation.

• Text-based documents

  Semi-structured content where labels, sections, and context need to be preserved.

• Scanned documents

  Image-based sources may require OCR and separate confidence controls. OCR should not be implied when it is not supported.

Why it matters

Extraction can reduce repetitive transcription and make large sources easier to review. It can also scale an error quickly if the wrong field, unit, date, sign, currency, or destination is accepted without review.

Financial workflows therefore need provenance and control. The reviewer should be able to inspect the source excerpt or row, understand how the value was interpreted, see any confidence or validation state, and approve what happens next.

What goes into it

• The source, access method, and intended downstream purpose
• The fields or records to retrieve
• Source context such as period, currency, units, and location
• Parsing, confidence, and validation rules
• A review and approval boundary before downstream write

Illustrative reviewed extraction

How RunwayCal helps

Common mistakes

• 1Treating extraction as inherently automated or assuming every automated method uses AI.
• 2Assuming an extracted value is correct because the source was read successfully.
• 3Losing the source excerpt, period, currency, unit, or destination context needed for review.
• 4Writing suggestions directly into financial records without an appropriate approval boundary.
• 5Claiming OCR, document coverage, or automatic save beyond the verified product workflow.