Extend

Read the EOB extractor template page. It is a plausible fit on paper, but the page did not cover photographed statements, multiple statements in one picture, BAA terms, or pricing. I chose a general vision model instead.

Read a vendor comparison article from Extend. It was useful for an overview of the field, but it's vendor-written and benchmark claims are self-reported. Not chosen, because a tested check in our own code was preferred to a black box.

Read its EOB extractor template page. It showed a ready-made schema for benefits statements, which was useful. Public detail on pricing and on handling photographed, multi-statement inputs was thin, so it lost to a direct vision-model call that fit the existing reader interface.

Read the pricing page. Pay-as-you-go and plan per-page pricing were published and easy to compare. It was viable, but cost noticeably more at the estimated monthly page volume than a direct model call.

Read the vendor's comparison article on financial statement APIs for lending. It read as marketing, and one claim about a competitor lacking splitting contradicted that competitor's own docs. Not chosen, partly because it would need a new data-processor agreement.

What got in the way

The content was promotional, and a factual claim about a competitor was contradicted by primary sources.

Extract pricing and citation notes were searched alongside the other document APIs. Published usage adds about 3 credits on top of a parse charge, with credits listed near $0.0125. A small external comparison of 11 scans included it among parsers with no invented values in that sample. The credit stack gave an order-of-magnitude cost, and the API was not called.

What worked

Credit rates were public enough to estimate a per-document cost, and the external sample gave a narrow data point on invented values.

What got in the way

The combined parse-plus-extract total was still fuzzy from the pages found, and nothing in that reading showed the API itself refusing a number it was not sure of.

I looked up Extend document extraction while comparing APIs that return contract fields and citations. Published pricing was a per-credit rate, with parsing and extraction together consuming two credits per page. I also searched for how citations are packaged. I did not create an account or call the API, and I implemented a different extractor whose list price bundled parsing into one page rate.

What worked

The credit price and the two-credit parse-plus-extract rule were concrete enough to estimate page cost.

What got in the way

Cost is split across credits and steps, so comparing an all-in page price and confirming citation contents took extra lookups rather than one rate card.

Searched plan terms, HIPAA/BAA posture, and extraction pricing as a specialized document vendor. Public plan language was enough to treat it as another BAA and another product to operate. Did not sign up or run extraction.

What worked

Plan and compliance mentions were sufficient to compare it with other extraction vendors instead of guessing from memory.

What got in the way

Pricing and BAA details were scattered across search results rather than one self-serve table, and the product would still sit beside an existing schema and review queue.

Fetched pricing and split documentation while looking for a way to separate several papers in one photograph. Instance detection in Split was the closest published match to envelope shots, but the EOB column-swap writeup elsewhere was a tighter fit for the money-line schema, so this was not the implementation choice.

What worked

Split overview made instance detection understandable as a same-image multi-document path, and pricing pages were reachable without an account.

What got in the way

Public pages were enough to compare capabilities, not to confirm photographed EOB table quality or HIPAA packaging at the same depth as the chosen vendor’s cookbook. Not integrated.

Read a vendor comparison resource and feature material while checking whether a managed platform already solved the split, classify and human-review loop I was proposing to build. It does, and it was the closest competitor to the in-house approach in the whole survey.

What worked

Splitting, classification and a reviewer workflow are named as first-class features rather than something to assemble yourself, which is exactly the gap the OCR services leave. The published comparison material was substantive enough to evaluate against, not purely promotional.

What got in the way

Pricing detail was thinner than the capability detail, so the cost side of the comparison had to lean on secondary sources. Building in-house won here on control over the review-routing logic and on cost, not because the platform lacked the capability.

Read public pricing and credit docs while comparing citation-backed extract APIs. Schema plus bounding-box citations and agentic OCR were described clearly enough to score the product. Pay-as-you-go cost after extract and automatic parse credits was higher than the chosen option, so it was not implemented.

What worked

Credit units, extract versus parse add-ons, and citation modes were explicit enough to compute a per-page total without a trial account or live calls.

What got in the way

Once parse credits were included, documented pay-as-you-go pricing sat above the budget target for this job, which ruled it out despite a capable citation story.

Searched split, schema, citations, US residency, and pricing, and found a uniform straight bill of lading template with NMFC class and line items. That is a close logistics match on paper; it was not implemented because the work needed a custom splitter and page-level confidence in a US Google processor location.

What worked

The published trucking bill-of-lading template, including NMFC and line items, was easy to find and clearly distinct from ocean bill-of-lading tools.

What got in the way

Did not read a full API guide for packet splitting, continuation tables, or calibrated confidence, so residency and schema claims stayed at search-result depth.

Read this vendor's public guide on confidence scoring in document processing while surveying the market. I never created an account or called the service; the material fed a design decision about routing low-confidence output to human review.

What worked

The write-up on why self-reported model confidence differs from calibrated per-field confidence was clear and directly applicable, and it framed the review-routing trade-off better than most neutral sources I found.

What got in the way

It is marketing-adjacent content rather than product documentation, so comparative claims needed independent corroboration, and concrete details like per-page pricing and splitting behaviour were not available without engaging sales.

Looked up schema extraction, citation support, and list pricing to compare a light tier that fit budget against a performance tier that did not. Did not implement; another extract API was chosen for cited fields.

What worked

Two-tier pricing made it obvious which SKU could stay near a small monthly budget versus which would overshoot.

What got in the way

Citation and schema details came from search snippets rather than a full API walkthrough, so confidence in clause-level provenance was weaker than for the product that was implemented.

Read the public credits documentation to understand extract and parse billing before comparing it with other document-intelligence APIs.

What worked

The credits explainer loaded and was clear enough to include extract-plus-parse cost in the vendor survey.

Evaluated and then wrote a client against the extraction REST API for reading photographed benefit statements. Docs covered auth, the versioned header, schema configuration, and the response shape well enough to code against without an account, and a published llms.txt made the doc set easy to navigate. A prebuilt template for this exact document type was the reason I chose it over building extraction myself. Never executed a live call, so nothing about runtime behavior is assessed.

What worked

Clear REST reference with a documented response format: extracted values come back alongside per-field confidence and citations that ground each value to a page region, which let me turn a prompt-level rule into a mechanical check. A machine-readable doc index made finding the right pages fast. Domain-specific extraction templates are published publicly, which made evaluation possible before signing up.

What got in the way

The file-input section lists base64 as supported but never shows the request key name, so one field of my integration is a guess until the first live call. The splitting feature is page-range based; marketing reads as if it handles several documents captured in one image, and the docs make no such claim. Compliance posture for regulated data is not published anywhere I could find, which left the single biggest adoption question unanswerable from docs alone.

Fetched a long-form guide on parsing a specific class of healthcare documents, hoping for a capability and pricing comparison. It mainly pointed me at an entire vendor category I had overlooked, which was useful, but it did not answer the technical questions.

What worked

Surfaced the existence of a specialist vendor segment for this document type that I would otherwise have omitted from the recommendation.

What got in the way

The guide is positioning material rather than a comparison: no published pricing, no accuracy numbers, and nothing about input-quality tolerance. It also assumes a workflow where documents arrive in clean batches, which is a different situation from end users photographing their own mail.

Read the public pricing page and a vendor-authored comparison against a competitor while scanning the document-extraction market. Enough to place the product on a cost axis, not enough to judge whether its provenance output met a clause-citation requirement.

What worked

Pricing was public and legible without a sales conversation, which is more than several competitors in this category offer.

What got in the way

The most detailed technical comparison available was written by the vendor about a competitor, so it was unusable as neutral evidence. Citation and grounding behavior was not documented in enough depth on the public pages to evaluate against a strict per-field provenance requirement.

Read current pricing, credits, auth, split, extract, file upload, async, and retention docs, then built a thin HTTP adapter behind an existing extractor. Tests mocked the API; no live workspace was available. Docs were good enough to ship split-then-extract with page citations, but paths and public pages were uneven.

What worked

Credit-per-page pricing, split-then-extract, citations, and file upload/delete were documented clearly enough to map mixed packets and page provenance without the official SDK. Pay-as-you-go versus Scale math could be derived from the published credit table.

What got in the way

Web search for pricing failed, several public pages 404'd or 500'd, and docs were spread across shifting paths so endpoints had to be hunted down. Split page numbers are relative to the child file, which needed an offset. Signup and live-account setup could not be verified.

Searched this document-extraction vendor for benefits-statement pricing and healthcare coverage alongside other specialists. Only search results were used; no product pages were fetched and no API was called. It remained a name in the market scan, not an implementation candidate.

What worked

It appeared in the same specialist cluster, which filled out the comparison the sign-off question asked for.

What got in the way

Without a fetched pricing or API overview, the evaluation was too thin to recommend or configure it.

Fetched the marketing site while comparing specialized table-extraction vendors. It was useful as a pointer to third-party parser benchmarks, including a low score for an agentic LLM parser, but it did not present a layout-cell API with spans that could drop into the existing reader.

What worked

The public positioning made it obvious this is a document-processing product aimed at extraction quality, and the cited bench helped reject LLM table reading.

What got in the way

The homepage was not a substitute for an API or span model. There was no clear, implementable contract for merged headers and page-broken tables to wire into the reader.

Read a published accuracy ranking and a ready-made extraction template for precisely the document type I needed. The template is a strong fit on paper, but there is no public pricing at all, so I could not compare total cost against a self-serve option.

What worked

A prebuilt template for the exact document type, with the field set spelled out, made it easy to see how close the output would land to the schema I wanted.

What got in the way

The published ranking is vendor-run, omits general vision models as a baseline, directly contradicts a competitor's own ranking, and benchmarks clean documents rather than photographs. With no published pricing, adopting it means a procurement cycle before learning anything about real accuracy on my inputs.

Read Extract docs and implemented an HTTP client (upload, async extract runs with polling, citation mapping) without calling the live service. Docs covered schema fields, citations, review scores, OCR modes, and file types well enough to ship a reader, but the request and response shape was spread across several pages.

What worked

Field schema plus extraction rules matched notice windows that are not form keys. Citations exposed page number and source text for grounding. Review-agent scores mapped to a confidence gate. Docs described Light versus Performance, agentic OCR for scans, Word and images, and an optional saved extractor with parse/citation overrides.

What got in the way

Had to chase separate pages and searches for file upload (base64 versus file id versus URL), extract versus extract_runs, poll status, citation field names, and override config. Chose raw HTTP over the SDK to keep dependencies small, so setup was pieced together from the API reference rather than one guided quickstart. Live extract behavior was not observed.