How to Extract Data from Mortgage Documents with IDPForge

The Shape Of The Problem

A single loan package is rarely one document. A 22-page PDF might contain a W-2, two pay stubs, three months of bank statements, the loan application, and a driver's license scan, all in one file. Any pipeline that assumes "one file, one document" breaks immediately.

That assumption is where most off-the-shelf extraction tools quietly fail lenders. They're built to pull fields from a known form, not to first figure out where one document ends and the next begins inside a single upload. For mortgage intake, that's the part that has to be solved before extraction even starts.

Meridian's setup below shows what solving it actually looks like, stage by stage, including where it went wrong before it went right.

Step 1: Point The Source At Intake

Meridian's packages arrive through two channels: the borrower portal, which submits via API, and a shared underwriting inbox, which receives email attachments. IDPForge treats these as two separate sources rather than funneling everything into one intake point.

Each source carries its own tag, portal-upload or uw-inbox, set at the Source stage. That tag travels with the document through the rest of the pipeline, so volume and performance can be tracked separately later without having to guess where a file originated.

Step 2: Split Before You Classify

Split runs first, as it cuts the bundled PDF into separate documents by boundary, before anything is asked to identify what those documents are.

Only after splitting does Classify assign each piece a class from the taxonomy: INC.W2, INC.PAYSTUB, BANK.STMT, LOAN.APP, ID.DL. Cover letters or blank pages that match nothing route to a no-op destination. They're captured, not extracted, so nothing gets silently dropped and nothing gets forced into a schema it doesn't belong to.

The ordering matters more than it looks. Classifying the whole bundle before splitting would ask the model "what is this file?" when the honest answer is "five different things." Splitting first turns an ambiguous question into five clear queries.

Step 3: One Schema Per Document Class

Each class routes to its own schema instead of getting folded into one bloated form. A W-2 schema captures employer, EIN, wages, and tax year. A pay stub schema captures gross pay, net pay, pay period, and YTD earnings. A bank statement schema captures account holder, statement period, and ending balance. A loan application schema captures borrower name, requested amount, and property address.

Separate schemas keep confidence scores meaningful. A mixed schema with a long list of optional fields can't tell the difference between "this field is missing" and "this field doesn't apply here," and that ambiguity is exactly what shows up as noise in a review queue later. Four narrow schemas keep each confidence score tied to a real expectation.

Step 4: Validation Is Where The Value Is

Extraction gets the data out, and validation is what decides whether a processor ever needs to look at it. Meridian runs four rules after extraction, each tied to a specific failure mode loan processors already knew to check for by hand.

Notice that none of these rules reject a document outright. Every failure routes to a human, at a specific severity, for a specific reason. That distinction is what keeps a review queue from turning into a black box.

Step 5: One Queue, Not Five

Every exception lands in a single queue named "Loan file exceptions," filtered to LOAN.APP with any open exception, sorted oldest-wait-first. Two processors can work it.

Splitting by document type would have meant five separate queues and five separate ways for one pile to back up while another sits empty quietly. A single queue, sorted by wait time rather than document class, means the oldest problem always surfaces first, regardless of which validation rule flagged it.

Step 6: Coverage That Shrinks

Week one ran at 100% flat coverage. Every correction was reviewed, even ones the rules hadn't flagged, while the team learned what "correct" actually looked like for these specific documents from these specific sources.

By week eight, flat coverage had dropped to 8%. Two standing exceptions stayed at 100% regardless: loans above $750,000, and any processor still in their first 30 days. Coverage that shrinks as trust builds, with permanent exceptions for cases where trust shouldn't be extended yet, let two processors hold a queue that would have overwhelmed three people working manually.

What Went Wrong

None of this worked cleanly on the first pass. Three issues surfaced in the early weeks, and each one traced back to an assumption that didn't hold for Meridian's specific document mix.

The name-match rule misfired on co-borrower households. It initially compared every document against a single borrower name field, so a co-applicant's pay stub kept getting flagged as a mismatch even though nothing was actually wrong. The fix was matching against the full borrower list on the loan application instead of one name field.

A legacy bank portal's PDFs included extra blank separator pages, and Split mistook those blank pages for document boundaries. One three-month bank statement got cut into two separate documents as a result. The fix was a blank-page-skip rule added at Initialization, before Split ever ran.

The YTD earnings tolerance was originally too tight for semi-monthly pay schedules. Ordinary rounding on semi-monthly stubs kept tripping the tolerance threshold, flooding the queue with pay stubs that were actually fine. The fix was loosening the tolerance specifically for that pay frequency, rather than loosening it across the board and losing the rule's value elsewhere.

Each fix was narrow and specific to the failure it addressed. None of them required rethinking the pipeline.

Where It Landed

Extraction wasn't the hard part. Getting the split boundaries and validation rules right for this specific document mix is what took six to eight weeks, and it's the part most teams underestimate when they scope a project like this.

‍

*A note on this walkthrough: Meridian Home Lending is an illustrative scenario built to show how IDPForge's Split → Classify → Extract → Validate pipeline actually plays out on mortgage document intake; it isn't a real customer deployment. The specific numbers, failure modes, and fixes here are representative of what mortgage document mixes typically surface, not a guarantee of what you'll see. Your own document types will have their own edge cases and boundary problems, but the same principle holds: splitting before classifying, keeping schemas narrow, and routing every exception through a single queue is what turns extraction from a demo into something that survives contact with your real documents.