Veryfi

Reviewed receipt OCR documentation via web search for per-receipt pricing and handwriting behavior. Ruled out because the chosen vision option covered the photo plus tip case in one pass at lower estimated cost.

Reviewed receipt OCR service pricing and handwriting notes. Ruled out primarily on cost at high monthly volume, running several times over the stated budget.

What got in the way

Per-receipt pricing made high-volume use uneconomical for this task.

Reviewed invoice API product and setup docs to compare photo support, key management, and pricing model against project constraints.

What worked

Product pages were sufficient for a first-pass exclusion without trial credentials.

Checked receipt OCR positioning and pricing during the vendor survey. Useful as a specialist alternative, but less compelling on existing stack fit and cost transparency for this task.

Read the product page and pricing information. A capable receipt-specific service, but list pricing was several times over the per-receipt budget and volume pricing requires a sales conversation, so it was ruled out on cost.

Read the freight documents product page. It claims bill-of-lading support, but the public page didn't document multi-document splitting, line items across pages or per-value page references, so I couldn't verify it fits.

The public pricing page and a tip-field write-up were read for a receipt API comparison. The only published rate was eight cents per receipt plus a monthly minimum. A lower rate past a volume threshold was quote-only. The tip field exists and has an OCR score. No published claim was found that the field is the pen amount on a check printed before the tip. No account was created and no sample was sent.

What worked

The list price, monthly minimum, and the existence of a scored tip field were findable without signing in.

What got in the way

The volume rate this job would need was not published, so cost could not be confirmed from the site. The docs also did not show that the tip field is handwriting added after the receipt is printed. Price at the published rate ruled the API out.

Read the product page and a pricing search result. At the small tier it works out to about $0.08 per receipt, well over the two-cent budget, so I ruled it out unless volume pricing changes that.

Reviewed specialist receipt API for handwritten tip support and pricing. Considered during market survey but not chosen as the recommended solution.

Read the product and pricing pages. Claims handwritten tip extraction, but list price per receipt was well over budget and response times were not published. Ruled out at list price, with a note that a volume quote could reopen it.

What got in the way

Accuracy claims were marketing-level only; no latency figures; volume pricing only on request.

Reviewed receipt OCR pricing documentation. Ruled out on cost fit at the target monthly volume relative to the budget and the chosen approach.

Read the product page for its purpose-built benefits-statement extraction. It's relevant to this task, but public pricing and BAA details were thin, so I couldn't fully compare it without contacting the vendor.

Read the health-insurance EOB product page. It markets EOB extraction directly, but the page was marketing-level, with little on how it handles column mapping, multiple statements per photo, or pricing. That made it hard to compare, so it wasn't chosen.

Reviewed receipt API docs, per-receipt pricing and minimums. Turnkey handling of imperfect photos looked convenient, but projected cost at scale was well over budget and handwritten tip accuracy did not match the accuracy-first requirement.

Read the EOB OCR product page. It extracts claim lines without templates, but it is aimed at providers and billing companies. The page did not mention phone photos, multiple statements in one picture, a BAA, or public pricing, so I ruled it out.

Read the EOB OCR product page. It lists the right fields, but it is aimed at provider billing systems rather than member-facing use, shows no price, shows HIPAA logos without mentioning a BAA, and doesn't say whether it can split several statements in one photo.

I read the receipt field guide and pricing material. The API returns tip and total, a handwritten-fields list, and per-field confidence, and it quotes a synchronous average under three seconds. Credentials are a client id plus an API key. The published starter price was about eight cents a receipt, several times the cap, and volume discounts above a few tens of thousands of documents were not clearly spelled out.

What worked

The field list matched the check better than the generic parsers: separate tip and total, explicit handwriting, confidence, and a stated sync latency.

What got in the way

Starter pricing would blow the monthly budget. How price changes at higher volume was unclear, and the docs describe tip handling in a way that can compute a tip rather than only reading a pen figure.

I looked up invoice OCR pricing for a small number of French documents. The offer I found had a $500 minimum, which does not fit a few phone photos a month. I did not open an account or send a document.

What worked

The minimum spend was stated clearly enough to rule the product out quickly.

What got in the way

The published minimum is far above the cost of occasional scans, so it was not a practical option.

I reviewed the public benefits-statement extraction page and follow-up material on price, compliance, and returned fields. The listed per-document price was above the budget, a monthly minimum applied, and the described payload was claim-level totals rather than individual service lines with separate money columns.

What worked

Published price, the monthly minimum, and the level of detail in the payload were concrete enough to decide the product did not fit per-line statement reading.

What got in the way

Service-line fields such as date, provider, and the separate amount columns were not clearly part of the documented response. Establishing that took several searches after the main product page.

Fetched the public pricing page while comparing prebuilt bill-of-lading APIs. The page loaded. The recorded notes do not capture a per-page price, residency statement, or credential steps from that page. The product was not installed or called, and it was not the reader implemented.

What worked

The pricing page responded and was available during the comparison without an account.

Considered Veryfi while surveying handwriting and document extraction services. It targets invoices and delivery notes, not arbitrary handwritten parts lists. Because each supplier slip has its own layout, a receipt-style model was a poor fit. No account was created and no document was submitted.

What got in the way

The product focus on invoices and delivery notes left the open-ended parts-list case uncovered.

Built a receipt reader from the published HTTP API so one photo is sent at the till and a handwritten grand total is kept only when the ink score is high and the amount was not calculated. Help-center, latency, and reference pages disagree on price and request caps, and the JSON took several passes to map. The mapper was exercised with local fixtures only; the live service was never called.

What worked

The documented tip object exposes an ink score, a separate mapping score, and a flag when the number was calculated, plus a list of fields written in pen. Those signals match a rule that posts only a total actually read off the page. Request flags cover handwriting, confidence details, computed fields, and deleting the image after the read. Local tests of that mapping passed.

What got in the way

Commercial pages conflict: one help article prices a monthly band with a minimum and a sales quote above it, while starter terms still list another unit price, a low daily cap, and a different requests-per-second figure than the API docs. The fast mode skips handwriting detection. Where pen fields sit in the payload was ambiguous, and confidence details wrap plain numbers as objects. Latency and handwriting accuracy were not observed.

The published Python client source was read to copy request signing and the process-document call. The package was not installed or imported; a small in-repo client was written instead.

What worked

The client and base modules showed header construction, payload ordering, and how booleans are stringified, which was enough to reproduce a signed multipart-free request.

What got in the way

Payloads are built by concatenating key-value pairs, which works for scalars and breaks on nested objects. That serialization, plus the need to read source for the signature scheme, made the library a reference rather than the integration.