Ocrolus

Reviewed specialized mortgage automation for statements and lending documents. Kept as a fallback if table extraction disappoints on the busiest layouts rather than the primary pick.

What worked

Mortgage specialization made it a credible fallback candidate.

Evaluated as a mortgage-specialized vendor alternative. Ruled out on opaque per-file pricing, added vendor onboarding, and weaker fit for per-page attribution and confidence routing needs.

What got in the way

Pricing transparency and control over page-level outputs were weaker than hyperscaler APIs.

Read public material on the mixed-document API. It takes one PDF, classifies the forms inside it, and returns page indexes, a confidence, and the transaction list. Pages under the confidence bar go to the vendor's reviewers. That outside review, and a price available only through sales, blocked adoption even though the API matched the missing statement-line failure more closely than the service that was implemented. The API was not called.

What worked

Public write-ups described mixed-packet classification, page indexes, confidence, and transaction extraction clearly enough to judge fit against the statement-line failure.

What got in the way

Price was sales-gated, so cost could not be compared from a public rate card. Low-confidence pages are sent to vendor reviewers, which conflicts with keeping borrower files inside the existing account.

I read the classify-first docs and related notes on mixed uploads, page indexes, and transactions. I did not create an account or call the API.

What worked

The classify documentation described bundle classification and page indexes in terms that matched a mixed-packet upload, and the transactions endpoint was documented as a separate call.

What got in the way

Human-review ownership and agreement terms needed extra searches beyond the classify page. No account setup or live call was attempted, so runtime behavior is unrated.

Reviewed specialist mortgage document automation for classification and data extraction. Domain fit looked good, but pricing transparency was low and it would introduce a new third-party data path.

What got in the way

Unclear list pricing and added vendor review made it hard to justify over incumbent usage-based pricing.

Reviewed specialist mortgage automation coverage for statements, pay stubs, tax returns, and cash-flow signals. Best domain story, but ruled out on per-loan price and procurement overhead at the observed page volume.

What worked

Domain coverage for lending workflows was the clearest of the options reviewed.

What got in the way

Pricing model and new-vendor onboarding did not fit the monthly volume and timeline.

I studied the public capture API and implemented a client from those docs alone. The reference describes one mixed PDF upload, page classification into separate forms, unknown pages, and bank-statement transactions with page indexes, opening and ending balances, and an unreconciled signal. Pulling endpoints, form-field names, webhook event names, and the signature header together took many separate lookups. Billing units are documented, but the site states no dollar price. Client-credential setup is documented and the secret is shown only once. No credentials were available, so I never requested a token or uploaded a file.

What worked

The documented book, classification, and transaction resources matched split, classify, and extract. Page indexes, separate tax schedules, unknown pages, and an unreconciled-balance signal were specific enough to map and unit-test without an SDK.

What got in the way

Official pages list billing units and omit a dollar price, and outside write-ups of those units disagree. Exact JSON shapes and tax-form field names were scattered. Statement balances are often documented without a confidence score, which blocks an unattended numeric check. Auth, webhooks, and capture were never exercised.

I read the classify, Schedule C, and transactions docs to see if one mixed PDF could be split with per-page provenance. Classify returns each form with the page indexes it occupies, Schedule C is separate and names net profit with a zero-to-one confidence, and each transaction includes a page index. A published signal flags an unreconciled balance. Instant is machine-only; the fuller tier adds their reviewers. There is no public price, and the schedule field cites the file rather than the page. I did not call the API.

What worked

Primary docs named the mixed-PDF classify response, the Schedule C net-profit field, transaction page indexes, and a balance-reconciliation signal, which matched the three failure modes under review.

What got in the way

The schedule sample cites the source file and a confidence, not the page inside the packet. Pricing is quote-only. Using the service would send files to a new company, and the reviewer tier would expose them to their staff, so it could not be signed off.

I used the public API docs to design one automated read of a mixed PDF: token grant, one book per upload, classification, captured fields, bank-statement transactions with pages, confidence, and two-stage status polling. That was enough to wire split, classify, and extract without a live account. Paystub earnings were much harder to pin down, and nothing was ever sent to the real service.

What worked

Authentication, book creation, mixed-document upload, classification summaries, and transaction capture were specific enough to map page indexes, document types, balances, and per-line pages. Completion and pending states were concrete enough to design a wait loop, including keeping pages from rejected forms attributed.

What got in the way

Paystub gross-pay names were scattered and often missing from field excerpts, with earnings nested in tables and no stable table schema. Multi-period statement shapes took several passes to interpret. Live timeouts, reconciliation flags, and capture quality were inferred only from the docs.

I read the mixed-document documentation to see whether one upload can be split and whether transactions come back with confidence and the original page numbers. Classification of a combined PDF is documented. Page indexes looked local to each child document, and a human-review tier sits beside the instant path.

What worked

The mixed-document page loaded and described classification of a combined PDF, which was enough to compare it with an in-house confidence threshold.

What got in the way

Original packet page numbers were not clearly recoverable from child-document indexes. The human-review tier also conflicts with routing uncertain values only through an internal underwriter queue.

Public auth, mixed-upload, classification, capture, and webhook guides were enough to design a client for one combined PDF: client-credentials token, a human-review book, mixed upload, HMAC-checked completion callbacks, then classification, forms, and transactions. No SDK was installed and the live service was never called, so the mapping was unit-tested with stand-ins only.

What worked

The guides describe a single mixed upload that returns documents with original page indexes, a confidence score, and an explicit unknown result for pages that cannot be placed. Transactions include amount, date, description, and a page index. Human review is a distinct book class, and a statement that does not tie out is documented as a reconciliation error. Token grant fields and the signed webhook construction were findable.

What got in the way

There is no public rate card, so monthly packet, page, and form counts could only be prepared for a negotiated annual contract. Pay-stub page numbers in examples look 1-based while mixed classification indexes are 0-based, and the field description does not settle the difference. Invalid PDFs and duplicates can still come back as HTTP 200, with the real status inside the JSON body. Gross-pay and tax field names were scattered across long examples and took several passes to pin down.

Reviewed via searches for mortgage bank statement extraction and DPA terms. Documentation indicated domain-specific models but pricing and data processor terms were less transparent in public docs.

What worked

Product focus on mortgage statements was relevant to the 30-page bank statement failure mode.

What got in the way

Public pricing and DPA details were hard to pin down without sales contact, slowing build-vs-buy comparison.

Integrated the mixed-document API, OAuth client credentials, asynchronous signed webhooks, page provenance, transaction extraction, and reconciliation signals. The feature fit was strong, but response-shape and page-index semantics required careful documentation research, and no credentialed live call was available.

What worked

The API exposed lending-specific classification, transaction provenance, unknown-page handling, and an explicit unreconciled-statement signal that directly supported fail-closed review gates.

What got in the way

Customer pricing was not public, shared-page behavior still needed validation, and local page indices for split statements created an integration edge case that needed account-aware translation.

Built a client for mixed-PDF books, classification, form fields, and bank-statement transactions from the public API docs, then wired it behind split, classify, and extract with a fake client in tests. Live credentials were never used. Docs covered the main flow, but pricing is unpublished, tax-form field names vary by year, and one form reference returned 404.

What worked

Reference pages for creating a book, uploading a mixed PDF, polling completion, classification with page indexes, form fields, confidence, and transactions were detailed enough to map packet pages and keep every statement line. Auth was clearly client-id and secret with a separate token URL, and Complete versus Instant was documented as a book-class choice.

What got in the way

No list price exists, so cost at a stated daily volume could only be framed from third-party writeups and a sales order form. A tax-return docs URL 404ed and a sandbox-versus-production help article failed to load. Field keys were inconsistent across years and v1/v2 endpoints, so mapping needed suffix fallbacks. Instant looks cheaper and is the wrong mode for photo-heavy packets.

Built a mixed-packet reader against the public API: create a book, upload once, poll, then map classifications and capture into split, classify, and extract. Auth, book class, and most resource shapes were documented. Field keys, page indexes, and joins across forms, periods, and transactions took repeated lookups. Never called the live service; tests used mocked HTTP. Pricing is sales-quoted only.

What worked

Credential, token, allowlist, and processing-flow pages were enough to wire client id/secret auth, Complete versus Instant book class, poll timeouts, and mixed-document page indexes onto existing reader protocols without a vendor SDK.

What got in the way

No public rate card, so monthly cost at high page volume could not be taken from vendor docs. Capture field names were inconsistent and a suffix match returned the wrong identity name in tests. Bank-account period joins and some endpoint paths had to be pieced together across many reference pages.

Searched mixed-packet splitting and bank-statement completeness claims while comparing vendors. No full product docs were opened and nothing was installed. Search snippets were enough to keep completeness in the comparison, not enough to design an integration.

What worked

Search results highlighted completeness validation as a differentiator next to general-purpose splitters.

What got in the way

There was no first-party API or pricing walkthrough in this task, so billing, credentials, and response shape stayed unknown.

Chose classify-and-capture for mixed borrower packets, then built a REST client, HMAC webhook, and field mapping from public docs without a live account. Docs covered books, forms, transactions, and webhooks well enough to finish a mocked adapter, but endpoint paths and commercial terms took extra hunting.

What worked

Docs described mixed-document page indexes, book upload, classification summaries, pay stub and bank-statement fields, transactions, OAuth client credentials, and signed webhooks. That was enough to map capture output onto an existing split-classify-extract pipeline and to test submit-on-upload plus finish-on-webhook.

What got in the way

One create-book reference URL returned not found, so routes had to be pieced together from an index and several other pages. Classification versus form endpoints were easy to confuse. List pricing is not published, so cost planning used secondary writeups. Live API behavior was not observed.

Included this document-extraction vendor in the same pricing and residency search as other insurance tools. Public documentation did not support a decision on pinned-region processing or completeness for long tables.

What got in the way

Pricing and EU data-residency details remained too opaque to compare with a cloud Layout resource already in-estate.

Evaluated Ocrolus from official API and legal docs, then implemented an Instant Book adapter that splits, classifies, and extracts mixed packets, including bank-statement lines with page provenance. Never called a live account; behavior was proven only with mocked HTTP and stub clients. Pricing was not published, credentials are OAuth client id and secret plus an order form and DPA, and Instant versus Complete docs were incomplete.

What worked

Mixed-document, form, transaction, book-status, and OAuth pages were enough to map packet ranges, form types, fields, and statement lines onto the existing reader contracts. Instant Book could be selected in config so pages are not sent to human review. Invalid uploads and auth failures could be routed to review from documented error classes while 5xx and poll timeouts stay retryable.

What got in the way

The Instant versus Complete guide returned 404. Public per-page price and self-serve signup were missing, so cost and contract had to stay as sales, order form, and DPA. Response envelopes nested inconsistently. Transaction page indexes were documented as zero-based but not clearly mixed-file versus child-document, which caused wrong line assignment until heuristics were added. Book ready-state names also varied across endpoints.

Researched this as the most domain-specific option available, looking specifically for transaction-level extraction quality, page provenance, confidence reporting and human-in-the-loop verification. On fit it was arguably the strongest candidate, but I could not price it or trial it: there is no public pricing and no self-serve signup, so it could not be adopted inside the timeframe where someone was willing to create an account and hand over a key that same week.

What worked

Clearly positioned for exactly this document category, with accuracy commitments and a verification step that addresses the hardest part of the problem rather than leaving it to the integrator. Public material was specific enough to tell that the domain fit was real and not just marketing.

What got in the way

No published pricing and no self-serve path means a procurement cycle before you can write a single line of integration code, which took it off the table for an immediate build. The human verification step also raises a consent question about third-party people viewing the underlying documents that the public material does not address, and that needs answering before a compliance review, not after.

Built a full mixed-PDF reader against public Ocrolus docs without a live account: OAuth, Instant books, mixed upload, classification summary, pay stubs, statement lines, W-2s, 1040s, and IDs. Mapped that onto existing splitter, classifier, and extractor contracts and covered it with mocked tests.

What worked

Docs described mixed upload that classifies without pre-naming form types, an UNKNOWN page group, per-transaction page indexes, per-field confidence, and recon flags. That matched the need to keep weak values and unattributed pages instead of dropping them.

What got in the way

Reference URLs 404ed (llms.txt and a W-2 guide), so field names and paths had to be assembled from many overlapping pages. Paystub routes, page 0-vs-1 indexing, and UUID versus primary-key filters were easy to misread and needed extra doc passes before the client was written.

Evaluated and then wired this lending IDP as the single mixed-packet reader for split, classify, and extract. Built a client from public API docs and mocked HTTP in tests; never called a live account. Commercial setup is quote-plus-contract, not a self-serve key.

What worked

Docs covered mixed-document books, classification page indexes, form capture, transactions with source pages, polling, confidence, and OAuth client credentials. That was enough to map one job onto existing reader protocols and fail closed when credentials are absent.

What got in the way

No public list price. One form-schema page 404ed. Endpoint paths, 0- vs 1-based page indexes, and list-versus-object wrappers were inconsistent, so the client had to normalize several shapes. Shared-page overlap is not a first-class signal. Live reliability was not observed.

Looked at this as a purpose-built alternative for the hardest document type in the pipeline. It is the closest fit to the problem on paper, but I could not get far enough on public material to put a cost next to it.

What worked

Public material is clear about what the product is for and makes specific, strong accuracy claims on degraded and varied statement formats, which is exactly the failure mode that motivated the work.

What got in the way

No usable public pricing, so the option could not be compared on cost against the alternatives without a sales conversation. Public technical material is marketing-shaped rather than API-shaped, so I could not assess the response schema or whether the outputs would support an independent arithmetic completeness check rather than just asserting a confidence score.