DEV Community: Smartdocs

How to Choose a Document Parsing API: What to Test Before You Commit

Smartdocs — Thu, 12 Nov 2026 08:01:16 +0000

TL;DR

A document parsing API turns PDFs, scans and images into structured JSON that software can use directly. Demos run on clean samples, so a good demo says little about your real inbox. This tutorial builds a small Python harness that runs your hardest documents through a candidate API and reports field accuracy, silent errors, latency and failures. It then shows the same harness against Sensible's API and lists what else to check before you commit: cost per document, who maintains the extraction logic, and how results get verified.

Business software depends on structured data, yet much of what companies receive arrives inside documents. Invoices, statements and forms show up as PDFs, scans and photos, each laid out differently by whoever produced it. For years the options were manual entry or brittle scripts.

A parsing API packs that reading work into one request, and many products now offer it. They all look good on a clean sample invoice, which makes them hard to compare. By the end of this tutorial you will know how to build a test set from your own documents, which numbers to measure, and how to read the results.

What One Supplier Invoice Looks Like After Parsing

Suppose we have an operations team at a mid-size distributor that receives supplier invoices from hundreds of vendors. Each vendor uses its own layout, some send digital PDFs, and others send scans. A person currently types the invoice number, date, line items and total into the accounting system.

A parsing API takes over that typing. The team's software sends a file and gets back JSON, a text format that programs read directly, with a named field for each value. The field names below are illustrative, because they depend on the configuration a team writes or clones.

{
  "status": "COMPLETE",
  "parsed_document": {
    "invoice_number": { "type": "string", "value": "INV-1042" },
    "total": { "type": "string", "value": "1,284.50" }
  }
}

OCR, short for optical character recognition, only converts the pixels of a scanned page into text. Parsing goes further by deciding which text is the invoice number and which is the total, so OCR is one step inside most parsing APIs rather than a substitute for them.

Four Approaches Sit Behind Most Parsing APIs

Knowing which approach a vendor leans on predicts where it will perform well and where it will need attention. Many products combine more than one.

OCR Services That Return Text From Each Page

OCR and text detection services return text, tables and form fields from a page. They suit teams that want raw material and will write the logic that decides which value is which.

Rule-Based Extraction Reads Values From Fixed Positions

Rule-based extraction defines where a value sits, using positions, labels or patterns. Results are predictable for stable layouts, though each new layout needs its own rules.

LLM-Based Extraction Answers Questions About the Page

LLM-based extraction has a language model answer questions such as "what is the invoice total?" It handles layouts it has never seen, but it can return a plausible wrong answer and can be slower and costlier per page.

Hybrid Extraction Chooses a Method for Each Field

Hybrid extraction applies rules to fields with predictable structure and an LLM to fields that vary, then validates the results. Each field uses the method that suits it.

How to Pick Between the Four Approaches

No single approach wins everywhere. A fixed government form favors rules, a free-text contract favors an LLM, and a mixed inbox favors a hybrid with a way to detect when either one is unsure.

How to Build a Test Set From Your Hardest Documents

A vendor demo on a clean sample invoice tells you little about production. A better test uses 20 to 30 of your own documents, chosen to include the cases that cause trouble today. Hand-label the correct values once, then reuse the set for every vendor you try.

Sort Documents Into Folders by Difficulty

Sort the files into folders by the kind of difficulty they carry:

clean/ holds a few easy digital PDFs as a control.
scans/ holds photographed or scanned pages with skew, noise or stamps.
variants/ holds the same document type from many vendors, so one field appears in several layouts.
long/ holds multi-page documents with repeating rows, such as a 40-line invoice.
high-stakes/ holds documents where a wrong value costs money, such as payment amounts.

docs/
  clean/invoice-001.pdf
  scans/invoice-014.pdf
  variants/invoice-021.pdf
  long/invoice-033.pdf
expected/
  invoice-001.json
  invoice-014.json

Label the Correct Values Once by Hand

Each file in expected/ shares its name with a document and lists the correct values. Set aside a handful of documents and don't use them while you tune anything, so you have an unbiased check at the end.

{
  "invoice_number": "INV-1042",
  "subtotal": 1180.00,
  "total": "1,284.50",
  "line_items": [{ "amount": 590.00 }, { "amount": 590.00 }]
}

A Vendor-Neutral Python Harness for Comparing Parsing APIs

How the Vendor Adapter Feeds the Test Runner

The harness below treats every vendor the same way. An adapter takes a file path and returns two things: a dictionary of extracted fields and a flag for whether the vendor marked the result as doubtful. The runner compares each field with your expected value and prints results per folder.

The runner also recomputes one rule of its own, that line items add up to the subtotal. That keeps the result from depending on whether a vendor chooses to flag a problem. Install requests, save the file as bench.py, and adjust the field names to match your documents.

import json
import pathlib
import statistics
import sys
import time
from collections import defaultdict

from adapter_sensible import extract  # swap in any vendor's adapter with the same shape


def norm(v):
    if isinstance(v, list):
        return [norm(x) for x in v]
    if isinstance(v, dict):
        return {k: norm(x) for k, x in v.items()}
    if v is None:
        return None
    s = str(v).strip().lower().replace(",", "").replace("$", "")
    try:
        return round(float(s), 2)
    except ValueError:
        return s


def reconciles(got):
    """Your own check, so the result never depends on the vendor flagging a problem."""
    items, subtotal = got.get("line_items"), got.get("subtotal")
    if not items or subtotal is None:
        return True
    try:
        total = sum(float(str(i["amount"]).replace(",", "").replace("$", "")) for i in items)
        return abs(total - float(str(subtotal).replace(",", "").replace("$", ""))) < 0.01
    except (KeyError, ValueError):
        return False


def run(adapter, docs_dir, expected_dir):
    rows, failures = [], []
    for pdf in sorted(pathlib.Path(docs_dir).rglob("*.pdf")):
        want = json.loads((pathlib.Path(expected_dir) / f"{pdf.stem}.json").read_text())
        started = time.perf_counter()
        try:
            got, vendor_flagged = adapter(pdf)
        except Exception as exc:
            failures.append((pdf.name, str(exc)))
            continue
        secs = time.perf_counter() - started
        flagged = vendor_flagged or not reconciles(got)
        for field, expected in want.items():
            rows.append({
                "group": pdf.parent.name, "doc": pdf.name, "field": field,
                "ok": norm(got.get(field)) == norm(expected),
                "flagged": flagged, "secs": secs,
            })
    return rows, failures


def report(rows, failures):
    by_group = defaultdict(list)
    for r in rows:
        by_group[r["group"]].append(r)
    for group, rs in sorted(by_group.items()):
        acc = sum(r["ok"] for r in rs) / len(rs)
        silent = sum((not r["ok"]) and (not r["flagged"]) for r in rs)
        print(f"{group:<12} fields={len(rs):<4} accuracy={acc:.1%}  silent_errors={silent}")
    secs = sorted({(r["doc"], r["secs"]) for r in rows}, key=lambda t: t[1])
    times = [s for _, s in secs]
    if times:
        p95 = times[min(len(times) - 1, int(len(times) * 0.95))]
        print(f"latency p50={statistics.median(times):.1f}s  p95={p95:.1f}s  failed_docs={len(failures)}")
    for name, err in failures:
        print("FAILED", name, err)


if __name__ == "__main__":
    report(*run(extract, sys.argv[1], sys.argv[2]))

Why Silent Errors Are the Number to Watch

The number to watch is silent_errors. A silent error is a wrong value that arrives without any flag, so nothing stops it from reaching your database. A wrong value that gets flagged costs a review; a wrong value that does not get flagged costs whatever the value controls.

What the Harness Output Looks Like

A dry run with three fake documents prints lines in this shape, and your own run will show the same columns with real numbers:

clean        fields=4    accuracy=100.0%  silent_errors=0
scans        fields=8    accuracy=75.0%  silent_errors=1
latency p50=0.0s  p95=0.0s  failed_docs=0

Adapting the Harness to Sensible's REST API

Calling the Synchronous Endpoint for Testing

Sensible exposes a REST endpoint per document type. The synchronous call is intended for testing, so it suits a harness: post the file bytes with a matching Content-Type and read parsed_document from the response. Authentication uses an Authorization: Bearer header with a key from the account page.

The adapter below also strips Sensible's {"type": ..., "value": ...} wrappers so results compare cleanly with your expected JSON. It reads validation_summary to see whether any validation rule raised an error or a warning. Set SENSIBLE_API_KEY in your environment and pass the name of your document type.

import os
import pathlib
import time

import requests

BASE = "https://api.sensible.so/v0"
HEADERS = {"Authorization": f"Bearer {os.environ.get('SENSIBLE_API_KEY', '')}"}


def plain(node):
    """Strip Sensible's {"type": ..., "value": ...} wrappers down to plain values."""
    if isinstance(node, dict) and "value" in node:
        return plain(node["value"])
    if isinstance(node, dict):
        return {k: plain(v) for k, v in node.items()}
    if isinstance(node, list):
        return [plain(v) for v in node]
    return node


def from_response(body):
    summary = body.get("validation_summary") or {}
    vendor_flagged = (summary.get("errors", 0) + summary.get("warnings", 0)) > 0
    return plain(body.get("parsed_document", {})), vendor_flagged


def extract(path, doc_type="invoices"):
    """Synchronous endpoint: intended for testing, not for production volume."""
    resp = requests.post(
        f"{BASE}/extract/{doc_type}",
        headers={**HEADERS, "Content-Type": "application/pdf"},
        data=pathlib.Path(path).read_bytes(),
        timeout=120,
    )
    resp.raise_for_status()
    return from_response(resp.json())


def extract_async(document_url, doc_type="invoices", poll_secs=2, timeout_secs=300):
    """Production path: submit a URL, then poll until the extraction finishes."""
    start = requests.post(
        f"{BASE}/extract_from_url/{doc_type}",
        headers={**HEADERS, "Content-Type": "application/json"},
        json={"document_url": document_url},
        timeout=60,
    )
    start.raise_for_status()
    extraction_id = start.json()["id"]
    deadline = time.monotonic() + timeout_secs
    while time.monotonic() < deadline:
        body = requests.get(f"{BASE}/documents/{extraction_id}", headers=HEADERS, timeout=60).json()
        if body.get("status") == "COMPLETE":
            return from_response(body)
        if body.get("status") == "FAILED":
            raise RuntimeError(f"extraction {extraction_id} failed")
        time.sleep(poll_secs)
    raise TimeoutError(f"extraction {extraction_id} still running after {timeout_secs}s")

Calling the Asynchronous Endpoint for Production

The extract_async function shows the production path. It submits a URL the API can fetch, then polls GET /documents/{id} until the status is COMPLETE or FAILED. Sensible's asynchronous tutorial walks through the same calls, and a webhook can replace the polling loop.

Run the harness with python bench.py docs expected. To compare another vendor, write an adapter with the same two return values and change one import line.

Six Checks to Read Out of the Harness Results

The numbers only help when you know what each one is testing. These six checks turn a run into a decision.

Check 1: Accuracy Per Field Across Vendor Layouts

Read the variants/ line first, because layout variation is where most parsing projects stall. If accuracy there is far below clean/, the product depends on layouts it has already seen. Also look at which fields fail, since one weak field, such as a tax amount, can do more damage than a low average suggests.

Check 2: Silent Errors Versus Flagged Errors

Count the silent errors per folder and compare vendors on that number as well as accuracy. Ask whether you can write your own rules and what happens to results that fail them. In Sensible, you write validation rules against the extracted values, for instance confirming that line items sum to a stated subtotal, and any field that fails gets flagged for review instead of passing through unverified.

Each rule is a JsonLogic condition with a severity of error, warning or skipped, and results appear in the validations array and the validation_summary counts. Sensible's validation page shows a rule that checks a field is present, written as {"exists":[{"var":"invoice_number.value"}]} when adapted to our invoice field.

Confidence signals are a separate tool. They are available only for the Query Group method, with values such as multiple_possible_answers and answer_not_found, and an LLM can report them inaccurately. Rules are the safer check for any field where a wrong value is costly.

Check 3: Repeating Rows on Long Multi-Page Documents

Long tables expose limits that short samples hide. Look at the long/ line and compare the number of extracted rows with the expected count, since a missing row can still leave other fields looking correct. Ask each vendor how it handles output that exceeds a model's response limit.

Sensible's List method, for example, splits a document into chunks, scores each chunk against your field descriptions, combines the top-scoring ones, and truncates the list if the output exceeds an LLM engine's limit. The Sections method suits repeating groups such as accounts on a statement, and it returns them as an array of objects.

Check 4: Latency From Submit to Result

Time each call and look at the median and the 95th percentile, because the slowest documents decide whether a workflow feels reliable. Test the synchronous endpoint for correctness, then time the asynchronous path from submit to COMPLETE, since production volumes use asynchronous calls. Latency also depends on how you call the API, so measure it from the environment where it will run.

Check 5: Who Fixes It When a Vendor Changes Format

Layouts change without notice, and somebody has to update the extraction logic when they do. Some teams have engineers write and maintain it, while others prefer prebuilt configurations or a vendor services team. Sensible keeps its configurations in Sensible, versioned through the API, and offers a library of more than 150 prebuilt ones that you clone to your account and test in the Extract tab.

Teams that do not want to build configurations themselves can have Sensible's managed services team build them from their own sample documents and adjust them when a vendor changes its format. Whichever route you choose, put a changed layout in your test set and see how long the fix takes.

Check 6: Cost Per Document at Your Volume

A per-page headline price rarely matches your bill, so divide the plan fee plus any overage by your monthly volume. Sensible's pricing page lists Growth at \$449 per month billed annually, or \$499 billed monthly, with 750 documents included and \$0.57 per extra document. For example, a team that processes 1,000 documents a month on annual billing pays \$449 plus 250 overage documents at \$0.57, which is about \$0.59 per document.

Scale lists \$1,349 per month billed annually, with 3,200 documents included and \$0.53 per extra document. Enterprise pricing is custom from 10,000 documents a month. SOC 2 Type II and GDPR appear on every plan, and HIPAA with a signed BAA is listed on Enterprise.

How Sensible Maps to the Six Checks

Sensible is a hybrid platform that combines AI extraction with deterministic, rule-based methods behind one REST API. Its unit of work is a document type, a named set of similar documents such as invoices, and each type holds one or more configurations written in SenseML, a JSON-based configuration language. Each field can use either kind of method: layout-based rules where a layout is predictable, and an LLM method where it varies. Both live in one configuration and return the same schema.

The notes below show how that hybrid design answers the earlier checks.

Layout Variation Follows an 80/20 Pattern

Sensible follows an 80/20 pattern, with deterministic methods handling most fields first and a generalized LLM-based template covering the rest.

Fallbacks Cover Fields That Return Nothing

Consecutive fields with the same ID let an LLM field back up a layout field, or the reverse, when the first returns an empty array or null.

Classification Routes Each Document Before Extraction

Classification matches a document to a document type before extraction, so a team can decide what to extract or where to route it in a mixed inbox.

Validation Rules Plus a Review Queue

Validation rules you configure check the output, and flagged documents can be corrected in a review queue.

The quickest way to judge all of this is to run your variants/ and long/ folders through a trial and read the harness output. The same harness works for every other API you shortlist.

Where Should You Start

A parsing API is easiest to judge on the documents that cause the most trouble: unusual layouts, repeating groups and values that cannot be wrong. Accuracy per folder, silent errors, tail latency, maintenance effort and cost per document together give a fuller picture than any demo. Keep the test set, because you will want it again when a vendor ships an update or your document mix changes.

Sensible offers a 14-day free trial with no credit card to start, so you can run the harness above against your own files. Start with the invoice extraction page to see a document type in the app, then send your hardest ten documents through the API.

Frequently Asked Questions What Does a Document Parsing API Return?

It accepts a file such as a PDF, image or spreadsheet and returns the data inside it as named fields, usually JSON. The values come back with a type, so software can act on them without retyping.

Is OCR Enough for Extracting Invoice Fields?

OCR converts the pixels of a scan into text and nothing more. A parsing API also decides which text is the invoice number, the date or the total. Most parsing APIs run OCR as one internal step when a file has no embedded text.

How Many Documents Should a Parsing Test Set Contain?

There is no fixed number. Twenty to thirty documents spread across clean, scanned, variant, long and high-stakes folders gives a useful first read. Add more documents wherever two vendors score close together.

Should I Test With Synchronous or Asynchronous Calls?

Use synchronous calls to check correctness, because they return the result in the same response. Use asynchronous calls to measure production behavior, where you submit a document and collect the result later by polling or through a webhook.

Does Sensible Use LLMs or Rules to Extract Data?

Both. Each field in a Sensible configuration can use a layout-based method for predictable structure or an LLM-based method for content that varies, and both return the same schema.

Does Sensible Validate Extracted Data Automatically?

Validation is configured by the team. You write rules in JsonLogic against the extracted values, and results that fail appear in the validations array so they can be flagged for review.

Instabase Alternatives: What Mid-Market Teams Choose

Smartdocs — Tue, 27 Oct 2026 10:40:16 +0000

TL;DR

Instabase is built for large enterprises processing complex, multi-document packets, and it sells that way, through a demo and a custom quote, with no public pricing. A mid-market team that just needs invoices, statements, or forms extracted into usable fields often finds that scale and sales process is more than they need. This piece looks at five platforms mid-market teams evaluate instead, including Sensible, and what each one is built for.

Getting Started: What Instabase Does and Who It's Built For

Instabase describes itself as an agentic automation platform that turns complex documents into what it calls verifiable intelligence, with capabilities like cross-document validation across a full "packet" of related files and dynamic selection of different AI models per task, according to Instabase's own site. Its customer list leans heavily toward large financial services, insurance, and public sector organizations, including names like AXA, NatWest, and Rocket Mortgage.

That scope shows up in how Instabase sells. There is no pricing published anywhere on its site. The only call to action is to request a demo, which puts every prospect through a sales conversation before they see a number. For an enterprise buying a platform to handle loan packets or claims files across thousands of documents a month, that process makes sense. For a mid-market team that wants to extract fields from invoices or bank statements and start seeing results in a week, it's a mismatch before the first call even happens.

The running example for this piece is a 60-person lending operations team at a regional fintech. They got a quote from Instabase after a demo call, and the number and implementation timeline both assumed a document volume and packet complexity the team didn't have. They went looking for something built closer to their actual size, and the five platforms below were what came up.

1. Sensible: Best for Mid-Market Teams That Want Self-Serve Configuration

Sensible is a document extraction platform built around SenseML, a configuration language where each field in a document type can use either a layout-based rule, for a format that's predictable, or an LLM-based method, for one that varies, with both returning the same schema either way. A team can see and version that configuration through Sensible's API, rather than having it live as an opaque model behind a sales-gated platform.

The difference that matters most for a mid-market team is how they get started. Sensible's pricing page lists two self-serve tiers: Growth at \$499 a month, or \$449 a month billed annually, for 750 documents a month, and Scale at \$1,499 a month, or \$1,349 a month billed annually, for 3,200 documents a month, each with a per-document overage rate beyond that. Every paid plan starts with a 14-day free trial that includes full access to extraction, validation, and the configuration editor, and no credit card is required to start it. A team can sign up, run their own documents through it, and see real output before talking to anyone, which is exactly the step Instabase's demo-only model skips.

For bank statements specifically, Sensible runs layout-based configurations for formats it has already mapped, plus a general LLM configuration that handles everything else, with both returning the same output schema. That's a narrower claim than "any format," but it means a new, unmapped statement layout still gets handled instead of falling through. Validation rules, like confirming that line items sum to a stated subtotal, get written once against the field names in the schema and flag any document that fails them, instead of requiring custom code the way an unstructured extraction pipeline does. Teams that don't want to own the configuration work at all can hand it to Sensible's managed services team, who build the extraction configuration from a team's own sample documents and adjust it when a format changes, on the same underlying engine available to self-serve customers. Output can also come back as an Excel or CSV file directly, either by calling the API with multiple extraction IDs or by selecting documents that already have extraction results and downloading them as Excel directly in the Sensible app.

2. Docsumo: Best for Teams Wanting a Guided Implementation

Docsumo offers a 14-day free trial that includes up to 1,000 free pages and ten user licenses, but its paid Business and Enterprise tiers are both listed as custom quotes rather than published prices, according to Docsumo's pricing page. The page also notes that setup fees are charged on top of the subscription, scaled to document complexity and the support level a team needs.

That structure fits a team that wants a vendor-led implementation rather than one it configures itself. Docsumo is a reasonable fit for finance and insurance teams that have a defined document set and want a guided setup, and a less direct fit for a team trying to compare real monthly costs before a sales call, since no self-serve paid plan exists.

3. Nanonets: Best for Self-Serve, Pay-as-You-Go Automation

Nanonets is the other genuinely self-serve option on this list. Its Starter tier is free to begin, moving to \$100 a month for 100 credits afterward, with signup requiring no card and \$50 in starting credits, per Nanonets' pricing page. Usage is metered per workflow step, called a block, at roughly \$0.02 for a simple block up to \$0.30 for a complex AI block, which the page estimates lands under \$2 per document for a typical invoice workflow.

The Growth and Enterprise tiers above Starter move to volume-based quotes and add classification, custom integrations, and compliance features like SSO and HIPAA support. For a mid-market team that wants to start small, see real per-document costs immediately, and scale usage without a new contract negotiation at every step, Nanonets' metered model is a close match to Sensible's self-serve approach, built around granular, pay-per-block pricing rather than Sensible's flat per-document plan tiers.

4. Rossum: Best for Finance Teams Needing Workflow Depth

Rossum lists a starting price of \$18,000 a year for its entry Starter tier, according to Rossum's pricing page, which already puts its floor well above Sensible's or Nanonets' self-serve entry points. Its Business, Enterprise, and Ultimate tiers above that show no published price and require a custom quote based on page volume, workflow complexity, and contract term.

Rossum's strength is workflow depth for finance-heavy document types like invoices and purchase orders, including approval routing and exception handling built into the platform rather than bolted on. That depth, and the price that comes with it, tends to fit teams with an established AP or finance operations workflow looking to replace an existing tool, more than a team trying to stand up extraction for the first time on a mid-market budget.

5. Hyperscience: Best for Large-Scale, Regulated Document Volume

Hyperscience is priced closer to Instabase than to any of the other four. Its entry tier starts at \$50,000 a year, with enterprise deployments running roughly €50,000 to €300,000 a year, according to erpresearch's pricing breakdown, and there is no free trial. The page places Hyperscience in the same enterprise intelligent-document-processing band as ABBYY and Tungsten, and notes that its machine-learning approach pays off mainly for organizations with enough document variety and volume to justify it.

That positions Hyperscience, like Instabase, as a platform built for large, often regulated document volumes where the per-document cost at scale matters more than the entry price or the time to a first extraction. A mid-market team evaluating it alongside Instabase is likely to run into the same mismatch: real capability, built for a scale and budget the team hasn't reached yet.

Where Should You Start

The real split across these five platforms isn't about which one can technically extract a field from a document, most of them can, on a clean sample in a demo. It's about whether a team can see real pricing and get a real extraction running before committing to a sales process sized for an enterprise buyer. Sensible and Nanonets publish self-serve pricing and let a team start immediately; Docsumo, Rossum, and Hyperscience all require a quote before a team sees a number, and Hyperscience's entry price alone puts it closer to Instabase than to a mid-market budget.

A team currently sitting on an Instabase quote that feels oversized for its actual document volume is a good candidate to try a self-serve platform directly against its own documents before signing anything. Sensible's 14-day free trial requires no credit card and gives full access to extraction, validation, and the configuration editor, which is the fastest way to find out whether a lighter platform actually covers what a team needs.

FAQs

What does Instabase actually do?

Instabase is an agentic document automation platform built for large enterprises, processing complex multi-document packets with cross-document validation and business rules applied by AI agents. It's built and sold for organizations in financial services, insurance, healthcare, and the public sector, with named customers like AXA, NatWest, and Rocket Mortgage.

Why doesn't Instabase publish pricing?

Instabase's pricing depends on document volume, packet complexity, and the specific workflows a customer needs automated, which is typical of enterprise software sold through a sales team rather than a self-serve signup. The only listed path to pricing is requesting a demo.

Which Instabase alternatives let a team see pricing without a sales call?

Sensible and Nanonets both publish self-serve pricing tiers that a team can sign up for directly. Sensible's Growth and Scale plans start at \$499 and \$1,499 a month respectively, each with a 14-day free trial and no card required, and Nanonets' Starter tier is free to begin with pay-as-you-go credits afterward.

Is Hyperscience a mid-market option?

Not based on its published pricing. Its entry tier starts at \$50,000 a year, with enterprise deployments running into the hundreds of thousands annually, which places it in the same band as large enterprise platforms like Instabase rather than alongside self-serve, mid-market tools.

What's the real difference between a self-serve platform and a quote-only one?

A self-serve platform lets a team see pricing and run its own documents through a trial before talking to anyone, which surfaces real fit and real output fast. A quote-only platform requires a sales conversation first, which usually means a longer evaluation cycle and a price shaped around the vendor's enterprise pricing model rather than a transparent, published rate.

Does a mid-market team ever need an enterprise platform like Instabase or Hyperscience?

Sometimes. Teams processing genuinely complex, multi-document packets at high volume, with cross-document validation needs across thousands of files a month, are the actual use case these platforms are built for. A team extracting fields from a single document type, like invoices or bank statements, at a few hundred to a few thousand documents a month usually gets there faster and cheaper with a self-serve platform instead.

Can extracted data from a self-serve platform still be exported into existing finance tools?

With Sensible specifically, yes. Results can be returned as an Excel or CSV file directly, either by calling the API with multiple extraction IDs or by selecting documents in the Sensible app and downloading them as Excel, without requiring a custom export script.

Top Ocrolus Competitors for Lenders and Fintech Teams in 2026

Smartdocs — Thu, 22 Oct 2026 06:53:45 +0000

TL;DR

Ocrolus built its platform specifically for lending, with bank statement and pay stub extraction backed by mandatory human review for accuracy. That review step is also what makes its cost and turnaround time variable, since pricing depends on how much human validation a document needs. This piece covers five platforms lending and fintech teams compare against Ocrolus, including Sensible, and what makes each one a fit or a mismatch for a lending document workflow specifically.

Getting Started: What Ocrolus Does and Who It Serves

Ocrolus describes itself as an AI workflow and analytics platform built for lenders, with document understanding specialized for bank statements, pay stubs, and tax documents, according to Ocrolus's own site. Its product line goes beyond extraction into fraud detection, cash flow analysis, and automated underwriting conditions, and its customer logos include PayPal, SoFi, Square, and Lendio, spanning small business lending, mortgage, auto finance, and consumer lending.

The part of Ocrolus that shapes how it fits (or doesn't) into a given team's workflow is its extraction method. Per Sensible's comparison of the two platforms, Ocrolus uses AI models paired with mandatory human-in-the-loop validation, and lets users choose between an "Instant" mode (faster, lower accuracy) or a "Complete" mode (slower, with human review). That human review step is also why Ocrolus publishes no pricing page: the comparison page describes its pricing as variable, depending on processing type and how much human validation a given document needs.

The running example for this piece is the underwriting team at a 45-person online consumer lender. They were running pay stubs and bank statements through Ocrolus's Complete mode to get the accuracy their credit decisions needed, and found both their monthly bill and their turnaround time moved around more than they could plan against. That unpredictability is what sent them looking at the alternatives below.

1. Sensible: Best for Lenders Who Want Predictable Cost Without Giving Up Accuracy

Sensible is a document extraction platform where SenseML, its configuration language, lets each field in a document type use either a layout-based rule, for formats that are predictable, or an LLM-based method, for ones that vary, with both returning the same schema. A team can see and version that configuration through Sensible's API, rather than depending on a human reviewer to catch what an AI model missed on every document that passes through.

That difference in approach drives the two practical gaps the comparison page draws between Ocrolus and Sensible. First, cost and turnaround time: Sensible's pricing page lists two self-serve tiers, Growth at $499amonth($449 billed annually) for 750 documents, and Scale at $1,499amonth($1,349 billed annually) for 3,200 documents, each with a flat per-document overage rate beyond that. There's no human-review surcharge that moves the bill depending on which documents needed extra validation. Second, speed to a working integration: every paid plan includes a 14-day free trial with full access to extraction, validation, and the configuration editor, no credit card required, so a lending team can run its own bank statements and pay stubs through the platform and see real output before committing to anything.

For bank statements specifically, Sensible runs layout-based configurations for formats it has already mapped, plus a general LLM-based configuration that handles anything unmapped, with both returning the same output schema either way. Validation rules, like confirming that line items sum to a stated subtotal, get written once against the schema's field names and flag any document that fails them, instead of routing every document through a human reviewer by default. Lending and fintech teams that don't want to own the configuration work can hand it to Sensible's managed services team, who build the extraction configuration from a team's own sample documents and adjust it when a lender or issuer changes its statement format, on the same underlying engine available to self-serve customers.

2. Docsumo: Best for Credit and Underwriting Teams Wanting a Guided Setup

Docsumo has built out dedicated lending coverage, with a solution aimed specifically at "credit, underwriting and loan operations teams." Its bank statement extraction is built to produce income and cash-flow figures ready for a credit memo, reconciling deposits against stated income, and it supports pay stubs, W-2s, 1099s, and both business and personal tax returns, according to Docsumo's own site. One of its lending customers, Grid Finance, reports extraction accuracy above 94% and under a minute of processing time per complex bank statement.

Docsumo's trial covers up to 1,000 free pages over 14 days with ten user licenses, but its paid Business and Enterprise tiers are both custom quotes rather than published prices, per Docsumo's pricing page, and the page notes that setup fees apply on top of the subscription, scaled to document complexity and support level. That structure fits a lending team that wants a vendor-led implementation with lending-specific document models already built, and is a less direct fit for a team that wants to see a real monthly number before a sales conversation.

3. Nanonets: Best for Fintech Teams That Want Metered, Pay-as-You-Go Pricing

Nanonets isn't built specifically for lending the way Ocrolus or Docsumo are, so a fintech team gets a general-purpose extraction engine rather than pre-built underwriting logic. What it offers instead is a close match to Sensible's self-serve model: a team can start small, see real per-document costs immediately, and scale usage without renegotiating a contract at every volume tier. Its Growth and Enterprise tiers above Starter move to volume-based quotes and add classification, custom integrations, and compliance features like SSO and HIPAA support.

4. Hyperscience: Best for Large, Regulated Lenders With High Document Volume

Hyperscience sits in a different pricing band entirely. Its entry tier starts at \$50,000 a year, with enterprise deployments running roughly €50,000 to €300,000 a year, according to erpresearch's pricing breakdown, and there's no free trial. That places it alongside large enterprise intelligent-document-processing platforms rather than self-serve tools, and its machine-learning approach is built to pay off for organizations with enough document variety and volume, think a bank or large regulated lender processing loan packets across multiple product lines, to justify the investment.

A mid-market or growth-stage fintech team evaluating Hyperscience against Ocrolus is likely running into a scale mismatch before it runs into a feature gap. Both platforms are built for lenders with established, high-volume document operations, which makes Hyperscience a reasonable alternative for a large bank's lending division and a poor fit for a team the size of the underwriting group in this piece's running example.

5. ABBYY Vantage: Best for Enterprise Lenders Already Standardized on RPA

ABBYY Vantage is a low-code enterprise intelligent document processing platform built around a Skill Designer and a marketplace of pre-trained document models, with connectors for RPA tools, per Sensible's comparison page. ABBYY says Vantage is ready to use within minutes for financial services documents including bank statements, utility bills, tax forms, and the broader set of banking documents tied to lending, and it also covers KYC document routing for onboarding.

Vantage requires a sales conversation for pricing and a guided proof-of-concept engagement before a team can fully evaluate it, with no self-serve trial or published rate. That consulting-led setup tends to fit an enterprise lender that already runs RPA tooling and wants document extraction wired into that existing orchestration layer, more than a fintech team trying to compare real costs and get a trial running the same week.

Where Should You Start

The split across these five platforms isn't really about which one can extract a field from a bank statement, most of them can, on a clean sample during a demo. It's about whether a lending or fintech team can see real pricing and get its own documents running through a trial before committing to a process built for Ocrolus's enterprise lending customers. Sensible and Nanonets publish self-serve pricing and let a team start the same day; Docsumo, Hyperscience, and ABBYY Vantage all require a quote or a guided engagement first, and Hyperscience's entry price alone puts it in a different budget tier than a growth-stage fintech is likely working with.

A team currently weighing Ocrolus's variable, human-review-driven pricing against its own document volume is a good candidate to test a flat-rate, self-serve platform directly against its own bank statements and pay stubs before signing anything. Sensible's 14-day free trial requires no credit card and gives full access to extraction, validation, and the configuration editor, which is the fastest way to find out whether a lighter platform covers what a lending workflow actually needs.

FAQs

What makes Ocrolus different from a general document extraction platform?

Ocrolus combines AI-based extraction with mandatory human-in-the-loop validation and lending-specific products like fraud detection, cash flow analysis, and automated underwriting conditions. That combination is built specifically for lending workflows, which is also why its pricing and turnaround time vary by how much human review a document needs.

Why doesn't Ocrolus publish pricing?

Per Sensible's comparison of the two platforms, Ocrolus's cost depends on which processing mode a document runs through and how much human validation it requires, which makes a flat published rate difficult to offer. The only way to get a number is through a sales conversation.

Which Ocrolus alternatives let a lending team see pricing without a sales call?

Sensible and Nanonets both publish self-serve pricing tiers a team can sign up for directly. Sensible's Growth and Scale plans start at \$499 and \$1,499 a month respectively, each with a 14-day free trial and no card required, and Nanonets' Starter tier is free to begin with pay-as-you-go credits afterward.

Is Hyperscience or ABBYY Vantage a realistic option for a smaller fintech team?

Not based on their published pricing and sales process. Hyperscience's entry tier starts at \$50,000 a year with no free trial, and ABBYY Vantage requires a guided proof-of-concept engagement before pricing is even discussed. Both are built for large, established lenders rather than growth-stage teams comparing options on their own.

Does mandatory human review make extraction more accurate?

Human review can catch errors an AI model misses, which is part of why Ocrolus requires it. The tradeoff is cost and turnaround time that move with document volume and complexity. Platforms that pair deterministic rules with LLM-based methods for the fields that need them, and let a team write validation rules against the extracted values, aim to reach similar reliability without a human reviewer on every document by default.

Can extracted bank statement or pay stub data be exported into underwriting or loan origination systems?

Do any of these platforms offer the fraud detection features Ocrolus provides?

Not as a direct, documented equivalent. Ocrolus's fraud detection and document authenticity checks are a distinct product built on top of its lending-specific document models. The platforms covered here compete primarily on extraction accuracy, pricing transparency, and setup speed rather than on matching that specific fraud-detection capability.

How to Convert Multi-Page Credit Card Statements to Excel Without Manual Entry

Smartdocs — Mon, 19 Oct 2026 12:32:28 +0000

TL;DR

A multi-page credit card statement is hard to convert to Excel because transactions, running balances, and account context split across page breaks, and every issuer formats that split differently. Manual entry is the default fallback, and it doesn't scale past a handful of statements a week before errors creep in. This guide covers why page breaks are the real technical problem, what a correctly converted statement actually needs to include, and how to get a reliable extraction running without re-keying every line by hand.

Getting Started: What Multi-Page Statement Conversion Actually Involves

A credit card statement is a PDF that lists an account's transactions for a billing cycle, along with a running balance, fees, interest, and payment history. Converting it to Excel means turning that PDF into rows and columns a spreadsheet can sort, filter, and total, without a person retyping each line.

For a single-page statement, this is close to a solved problem. Most PDF tools can pull a table off one page reasonably well. The difficulty shows up specifically with multi-page statements, where a table of transactions continues from the bottom of one page to the top of the next, and the second page usually has no header row, no account number repeated, and no obvious signal that it's a continuation rather than a new table. A tool built to read one page at a time treats each page as its own document, and the moment it does that, the statement breaks apart.

Why the Page Break Is the Real Technical Problem

Three things specifically go wrong at a page boundary, and any conversion method eventually has to handle all three:

Running balances lose their anchor. The balance column depends on every prior row. If a tool re-starts extraction on page two without knowing the closing balance from page one, the numbers it produces are disconnected from the actual account state.
Issuer formats vary in how they signal continuation. Some issuers repeat the account number and a "continued" label on every page. Others just keep listing transactions with no header at all. A method tuned to one issuer's layout often fails silently on another's.
Multi-account statements mix data mid-document. A business card statement covering several cardholders can switch from one account's transactions to another's partway down a page, with no page break to signal the change. A method that only watches for page boundaries misses this entirely.

Regional issuers change their statement layout more often than the big national ones, since they tend to run on smaller design teams and update templates without much notice. Any extraction approach that hardcodes a single layout eventually meets a statement it wasn't built for.

What People Try Before Finding a Reliable Method

Manual entry is where most teams start, and it works fine at low volume. Someone opens the PDF, reads each transaction, and types it into a spreadsheet. It's slow, and the error rate climbs with document length. A twelve-page statement with three hundred transactions is a different task than a one-page statement with fifteen, even though both get typed the same way.

Bank-provided CSV or QFX exports are the next thing people reach for, and they solve the problem when they're available. The catch is availability itself. Not every card issuer offers a downloadable export, and when a company processes statements from customers or vendors rather than its own accounts, there's usually no login to request an export from in the first place.

Generic PDF-to-Excel converters are the most common next attempt, and they're where the page-break problem shows up most visibly. These tools are built to detect tables on a page, and they do that reasonably well for a single page. Feed them a twelve-page statement and they return twelve separate, disconnected tables, with no shared running balance and no way to know that row 40 on page 3 continues row 38 on page 2. Someone still has to stitch the pieces together by hand, which is most of the original manual work, just with extra steps.

Where This Breaks Down at Real-World Volume

A regional credit union's lending team processes around fifty statements a week as part of income and debt verification for loan applications. At that volume, someone on the team was spending most of a workday just on statement conversion, opening each PDF, checking whether the transaction table continued past page one, and manually reconciling the running balance whenever it did.

The team tried a generic conversion tool to speed this up. It worked for statements from the two largest national issuers they saw most often, both of which repeat the account number and a running balance on every page. It failed consistently on regional and community bank statements, where the second page of a transaction table often had no repeated header at all. The tool would return the first page's transactions correctly and then either drop the second page's rows or merge them into the wrong table, and there was no way to tell which had happened without manually checking every output against the source PDF. That manual check ate back most of the time the tool was supposed to save.

What a Properly Converted Statement Has to Include

Whatever method does the extraction, the output needs to capture the statement at three levels, or a spreadsheet built from it will be missing the context that makes it usable:

Account-level data: card number (masked), statement period, credit limit, and both the opening and closing balance for the cycle.
Transaction-level data: date, merchant or description, amount, and category if the issuer provides one, with every row correctly assigned to its account even when a statement covers multiple cards.
Statement-level data: total fees, interest charged, minimum payment due, and payment due date, since these numbers usually live in a summary block that's easy for a page-by-page tool to miss entirely.

A conversion that gets the transaction rows right but drops the statement-level summary still leaves someone opening the original PDF to check the due date and minimum payment, which defeats much of the point.

How Sensible Extracts Multi-Page Statements Without Manual Entry

Sensible is a document extraction platform built to handle exactly the structural problems described above, rather than treating each page as an isolated table. It combines deterministic, layout-based extraction for the parts of a statement that follow a predictable structure with LLM-based extraction for the parts that vary, and both run through the same schema-validated output.

For the page-break problem specifically, Sensible includes table-continuation logic that tracks a transaction table across page boundaries rather than resetting at each new page. When a table's rows stop at the bottom of page one and pick up at the top of page two with no repeated header, Sensible recognizes the continuation and carries the running balance forward, instead of treating page two as an unrelated block of text. This directly addresses the running-balance and missing-continuation-signal problems described earlier.

For the issuer-variation problem, Sensible ships with prebuilt configurations for credit_card_statements and bank_statements that already account for common layout differences across issuers, and per-issuer configuration matching lets a team refine extraction further for a specific bank's format without rebuilding the whole pipeline from scratch. Configurations are written in SenseML, a declarative language managed through the API with its own versioning, so a fix for one issuer's layout doesn't have to be re-derived by hand every time that issuer tweaks their template.

For the multi-account problem, Sensible's multi-account statement splitting detects where one account's transactions end and another's begin within a single document, even when that split happens mid-page rather than at a page boundary, and routes each account's rows to their own output block accordingly.

Every extracted field carries a source-coordinate audit trail back to the original PDF, visible in the Sensible app, so a reviewer can check a specific number against the source document in seconds instead of re-reading the whole statement.

Getting a First Extraction Running

Getting started doesn't require writing a configuration from zero. Sensible's prebuilt credit_card_statements configuration handles common issuer layouts out of the box, so the first step is usually just sending a sample statement through the API or the Sensible app and checking the output against the source PDF. From there, a team can promote the configuration from a development environment to production once it's been tested against a representative sample of the statements they actually receive, and refine it further for any issuer whose layout the prebuilt configuration doesn't fully cover. Output comes back through a REST API or the Python and Node SDKs, in a schema that maps directly onto spreadsheet columns, so building the Excel file from Sensible's output is a formatting step rather than a data-cleaning one.

Where Should You Start

The core problem with multi-page credit card statements isn't extracting text from a PDF; most tools can do that much. It's that a transaction table, a running balance, and an account's identity all have to survive the transition from one page to the next, and that's exactly where naive, page-by-page tools fall apart. A method that treats a statement as one continuous document, rather than a stack of independent pages, closes that gap.

If statement conversion is currently eating hours of manual review every week, the fastest way to see whether this fixes it is to run one of the statements that's been causing the most trouble through Sensible's credit card statement extraction and compare the output directly against the source PDF. A 14-day free trial is available with no credit card required, which is enough to test against a real, messy sample rather than a clean demo file.

FAQs

Why do generic PDF-to-Excel tools fail on multi-page credit card statements specifically?

Generic tools typically process a PDF one page at a time and look for a table on each page independently. When a transaction table continues from one page to the next without a repeated header or account number, the tool has no signal that the two pages belong to the same table, so it returns them as separate, disconnected outputs instead of one continuous set of rows.

Does every card issuer format multi-page statements the same way?

No. Some issuers repeat the account number, statement period, and running balance at the top of every page. Others list transactions with no repeated header at all once the table continues past the first page. Regional and community banks change their statement templates more often than large national issuers, which makes a method tuned to only one layout unreliable across a mixed set of statements.

What data does a converted statement need beyond the transaction list?

A complete conversion needs account-level data (statement period, credit limit, opening and closing balance), transaction-level data (date, merchant, amount, category), and statement-level data (fees, interest charged, minimum payment, and due date). Tools that only capture the transaction rows typically miss the statement-level summary, which usually sits in a separate block that page-by-page extraction methods overlook.

Can a single statement contain more than one account's transactions?

Yes, this is common on business or shared card statements covering multiple cardholders. The transactions for different accounts can switch mid-page with no page break to mark the change, which means a method that only tracks page boundaries can merge two accounts' transactions into one table by mistake.

How is a running balance affected by a page break?

A running balance depends on every transaction before it in the statement. If an extraction method resets at each new page instead of carrying the balance forward, the numbers on page two are calculated with no reference to page one's closing balance, and the output balance column stops matching the actual account state.

Is bank-provided CSV or QFX export a reliable alternative to PDF conversion?

It's a reliable option when it's available, but availability varies by issuer, and it isn't an option at all for a company processing statements it doesn't have login access to, such as statements submitted by customers or loan applicants rather than the company's own accounts.

How long does it take to get a first statement extraction working?

With a prebuilt configuration for common statement layouts, the first extraction is typically a matter of sending a sample statement through and checking the output against the source PDF, rather than building a layout from scratch. Refining accuracy for a specific issuer's format on top of that usually takes longer, depending on how much the layout diverges from the common template.