*** September 2026 Major Release ***Read and watch
Document type

Extracting data from loan histories

A servicer keeps a line for every payment a loan has taken, printed on whatever report its software produces. A buyer reads the history before the loan trades. A court reads it when a borrower disputes what was paid, and servicing teams produce thousands a month, arriving as PDF exports.

A reviewer needs each payment's due and received dates, what it was split into and the balance it left behind. A boarding or audit system replays the history row by row and flags the payments that arrived late or went nowhere near principal.

Page 1 of a sample Loan History, with extracted values outlined
12,667Markdown characters
794parse blocks
755fields extracted
The problem

What makes loan histories hard

One table, dozens of rows

A loan's whole life runs as thirteen ruled columns over several landscape pages, with the header repeated at each break.

The irregular rows are the point

A partial payment, a late one and a short one sit among the regular rows, and those are the rows a reviewer is looking for.

Blank cells beside filled ones

A reference column is empty on one row, zeroes on the next and a number on the one after, with nothing to mark the difference.

How it works

Parse, extract, verify

1

Parse

Parse turns the document into reading-order Markdown and a hierarchy of blocks (text, tables, figures), and grounds each block to its exact location on the page.

2

Extract

You define the fields in a JSON schema, and Extract returns their values in a consistent, structured format, each linked back to where it appears in the Markdown.

3

Verify

Each value links back to where it appears, down to the character range in the Markdown, and the page and bounding box in the source document, so every result can be verified.

Worked example

One loan history, end to end

About this document: A loan payment history produced by Loan Servicing Soft, published as a sample of its software's output. Two landscape pages: a header with the servicer, loan and borrower, then one ruled table of 57 payments in thirteen columns, carried over the page break with its header repeated, and a total row. Page 1 is featured. The data is fictitious.

Processing objective: The objective is to lift one payment that went wrong, out of a table where every row looks alike. It fell due on the first of the month and arrived on the twentieth. It carried a late fee, and nothing at all reached principal.

Demonstration fields: Date due, Date received, Late fee, Applied to principal, Principal balance

The document

2 of 2 pages
  • Page 1 of the sample Loan HistoryPage 1shown below
  • Page 2 of the sample Loan HistoryPage 2

Where each value came from

Page 1 of the sample Loan History, with every featured field outlined
Date duepayments[7].date_due
2010-09-01
The region of the sample Loan History containing Date due, with the extracted value outlined

Printed on the page as 09/01/2010, normalized on extraction.

extraction_metadata["payments[7].date_due"]
{
  "value": "2010-09-01",
  "page": 1,
  "range": {
    "end": 1897,
    "start": 1887
  },
  "box": {
    "xmin": 0.01901,
    "ymin": 0.34933,
    "xmax": 0.10346,
    "ymax": 0.37385
  }
}
Date receivedpayments[7].date_received
2010-09-20
The region of the sample Loan History containing Date received, with the extracted value outlined

Printed on the page as 09/20/2010, normalized on extraction.

extraction_metadata["payments[7].date_received"]
{
  "value": "2010-09-20",
  "page": 1,
  "range": {
    "end": 1916,
    "start": 1906
  },
  "box": {
    "xmin": 0.10346,
    "ymin": 0.34935,
    "xmax": 0.18731,
    "ymax": 0.37386
  }
}
Late feepayments[7].late_fee
22.25
The region of the sample Loan History containing Late fee, with the extracted value outlined
extraction_metadata["payments[7].late_fee"]
{
  "value": 22.25,
  "page": 1,
  "range": {
    "end": 2029,
    "start": 2024
  },
  "box": {
    "xmin": 0.7133,
    "ymin": 0.34944,
    "xmax": 0.77899,
    "ymax": 0.37393
  }
}
Applied to principalpayments[7].principal
0
The region of the sample Loan History containing Applied to principal, with the extracted value outlined
extraction_metadata["payments[7].principal"]
{
  "value": 0,
  "page": 1,
  "range": {
    "end": 1985,
    "start": 1981
  },
  "box": {
    "xmin": 0.50494,
    "ymin": 0.34941,
    "xmax": 0.58252,
    "ymax": 0.3739
  }
}
Principal balancepayments[7].principal_balance
49,864.47
The region of the sample Loan History containing Principal balance, with the extracted value outlined
extraction_metadata["payments[7].principal_balance"]
{
  "value": 49864.47,
  "page": 1,
  "range": {
    "end": 1957,
    "start": 1949
  },
  "box": {
    "xmin": 0.31663,
    "ymin": 0.34938,
    "xmax": 0.42242,
    "ymax": 0.37389
  }
}

How to try it yourself

Everything on this page is reproducible. The sample, its schema, and the Parse and Extract API outputs are published. You can repeat the same two calls from whichever surface you already build on.

  • Claude Skilldescribe the job; the agent writes it
  • CLIno code at all
  • MCPexpose ADE docs as an agent tool
  • REST APIany language
  • Pythonlandingai-ade
  • TypeScriptlandingai-ade
Why LandingAI?

Documents into data

Accurate

The best accuracy on the difficult documents other tools get wrong, such as messy scans, complicated tables, checkboxes and handwriting.

Auditable

Every answer cites its sources. Values come back with an audit trail (page, bounding box, character range) so a human can review them.

Agentic

Applies multi-step reasoning, and plans before it acts. Handles documents it has never seen before and adapts to variations.

API-first

Composable APIs that drop into any tech stack and can be called from anywhere. Easy to build on and embed in your pipelines and products.

Affordable

Cost-competitive rates with complete price transparency. Spend controls before you run, and every job reports its exact cost.

Enterprise-grade

Built for production and scale from day one. Fully observable and monitored, running securely in our cloud or yours.

Built for high-volume, high-throughput production

  • Zero data retention
  • Priority rate limits
  • Enhanced support
  • VPC and on-prem deployment

Available on Team and Enterprise plans.

Compare plans
Capabilities

Loan History processing highlights

Every servicer's report layout
Full payment histories
Tables across page breaks
Thirteen-column ruled rows
Due and received dates
Principal and interest splits
Impound and escrow columns
Late fees and short payments
Running principal balances
Total rows that must agree
Dates normalized to ISO
Bounding box for every value
FAQs

Questions, answered

Every payment. Define the history as an array and each row comes back with its dates and its full split, including rows that continue past the page break under a repeated header.

Yes. Each row returns its own figures, so a payment with nothing applied to principal comes back with a zero in that column and the fee that went with it.

Yes. The total is a row like any other and comes back with the columns it sums. The rows above it can then be added up and checked against it.

Every value comes back with its page, a bounding box and the character range in the parsed Markdown. The box can be drawn onto the page image, so a reviewer sees the row it was read from.

A servicing history carries a borrower, a loan number and every payment they have made. A schema can ask for the payment rows alone. Accounts are available with zero data retention, alongside SOC 2 Type II, GDPR and HIPAA compliance.

Start extracting loan history data

Reliable, structured outputs with full traceability in minutes