{}

Income & Asset Verification: Automate Lending Document Intake

Pay stubsBank statementsW-2sTax returns (1040)Employment verification letters

The problem

Underwriters and loan processors spend hours reading and re-keying figures from stacks of borrower-submitted pay stubs and bank statements. It slows time-to-close, and it's exactly the kind of manual transcription where a single mis-keyed digit compounds into a bad income calculation.

How Dokyumi solves it

Pay stubs, bank statements, and tax returns don't look anything alike, so the right move is one schema per document type, each selected by slug on the shared extraction endpoint. A pay-stub schema pulls gross/net pay and YTD figures; a bank-statement schema pulls balances and transactions; a tax-return schema pulls AGI and withholding.

Borrowers or loan officers submit documents — directly through the API, or through a white-label upload portal you brand for applicants — and Dokyumi returns structured income and asset data with confidence and validation details. Inspect review results before mapping anything into your LOS or underwriting checklist.

Example schema and result

A real schema shape for lending & underwriting documents, and the JSON you get back from one extraction.

Example schema definition

{
  "slug": "pay-stub-parser",
  "name": "Pay Stub Parser",
  "description": "Extracts income figures from employee pay stubs for income verification",
  "ocr_mode": "standard",
  "fields": [
    {
      "key": "employer_name",
      "type": "string",
      "required": true
    },
    {
      "key": "employee_name",
      "type": "string",
      "required": true
    },
    {
      "key": "pay_period_start",
      "type": "date",
      "required": false
    },
    {
      "key": "pay_period_end",
      "type": "date",
      "required": false
    },
    {
      "key": "gross_pay",
      "type": "currency",
      "required": true
    },
    {
      "key": "net_pay",
      "type": "currency",
      "required": true
    },
    {
      "key": "ytd_gross",
      "type": "currency",
      "required": false
    },
    {
      "key": "federal_tax_withheld",
      "type": "currency",
      "required": false
    }
  ]
}

Result — POST /api/v1/extract

{
  "id": "16673186-ff55-4722-b968-8463b724cd2b",
  "status": "completed",
  "request_id": "8ad5f97a-70c5-4cf8-9a93-374c6bbb3196",
  "schema": "pay-stub-parser",
  "data": {
    "employer_name": "Meridian Logistics LLC",
    "employee_name": "J. Alvarez",
    "pay_period_start": "2026-05-16",
    "pay_period_end": "2026-05-31",
    "gross_pay": 3120,
    "net_pay": 2384.11,
    "ytd_gross": 15600,
    "federal_tax_withheld": 412
  },
  "confidence": {
    "gross_pay": 0.99,
    "net_pay": 0.98,
    "ytd_gross": 0.95
  },
  "validation": {
    "valid": true,
    "errors": [],
    "low_confidence_fields": []
  },
  "meta": {
    "processing_time_ms": 990,
    "page_count": 1,
    "credits_used": 1,
    "ocr_cached": false,
    "model": "anthropic/claude-sonnet-4"
  }
}

How it works

1

Create one schema per document type

Pay stubs, bank statements, and tax returns each get their own schema, selected by slug on the shared endpoint.

2

Collect documents from borrowers

Upload directly via your loan portal, or hand borrowers a white-label Dokyumi upload page.

3

Extract structured income/asset data

Each successful request returns data with a model-reported confidence map and validation details.

4

Review before underwriting use

Resolve validation errors and low-confidence fields before populating your LOS, spreadsheet, or decision engine; upload-site submissions can also use a configured webhook.

Lending & Underwriting FAQ

Does Dokyumi make the underwriting decision or verify income automatically?+
No. Dokyumi extracts the fields you define into structured data — the underwriting decision, DTI calculation, and any policy logic stay in your system or with your underwriters.
Can Dokyumi detect altered or fraudulent documents?+
No — it's a data-extraction pipeline, not a fraud- or authenticity-detection tool. Treat extracted figures like any borrower-submitted data, subject to your existing verification process.
Should pay stubs and bank statements share one schema?+
No — define a separate schema for each document type. The fields are different enough that a schema-per-doc-type keeps confidence scoring and validation accurate.
Can borrowers upload documents themselves?+
Yes, via a white-label portal (a branded upload page) you set up — available on every plan, with higher portal allowances on Growth and Enterprise.
Is this suitable for handling tax returns and other sensitive documents?+
You control exactly which fields your schema captures. See our security page for how we handle encryption, retention, and access controls.

Parser guides for these documents

Bank Statement Parser

Any bank’s statement format in — account details, balances, and the full transaction table out.

W-2 Parser

Turn employee W-2s into structured data with a model-reported confidence map and validation details.

Related use cases

Accounts Payable

Extract vendor, line-item, and total data from invoices and receipts — no template building, no AWS Textract setup.

Tax Prep

Turn client-submitted W-2s, 1099s, and 1040s into structured data — or hand clients a branded upload portal for intake season.

Real Estate & Leasing

Pull lease terms, applicant income, and insurance details out of leases, applications, and dec pages — no per-property template work.

Stop re-keying pay stubs by hand.

25 free credits every month — one credit covers a document up to 5 pages, with no credit card or AWS account required.