Taggun

Reviewed the data-fields guide and a verbose response sample to see if a tip amount is transcribed. Handwriting is exposed as a fraud flag rather than a written tip. Standard plan caps sit far below the monthly photo volume, so this volume would be a custom quote. A search of the verbose sample for a tip amount only hit unrelated upload wording.

What worked

The data-fields documentation and published plan sizes were enough to see that handwriting is a fraud signal and that off-the-shelf quotas do not cover the monthly volume.

What got in the way

Notes from earlier in the same survey disagreed on whether a tip amount exists. Searching the verbose payload for that field matched only unrelated multipart text, so the field list was harder to trust than a data-fields page should be.

Taggun was screened from search results for overage price and how handwriting is exposed. No product page was opened and the API was not called. It was dropped because handwriting is a fraud flag rather than a second total.

What worked

Search results were enough to see Advanced-plan overage near four cents per scan and to see that handwriting is surfaced as a fraud signal.

What got in the way

A fraud flag does not yield a pen-written total distinct from the printed total, so the service cannot close the receipt-versus-card gap this pipeline already models. Primary field docs were never opened, so the capability check stayed shallow.

I searched pricing and field documentation for the receipt API. The rate I found was still about twice the per-receipt budget. I did not find an official description of handwriting detection or a pen total kept distinct from the printed total. I did not create an account.

What worked

Published pricing was findable and high enough, on its own, to reject the API for this volume.

What got in the way

Handwriting behavior was not documented in the material I found, so there was no evidence it would read a pen grand total separately from the printed amount.

Pulled the public site while comparing managed extractors and could not answer a single one of my four decision criteria from it. Pricing is unpublished, handwriting is not mentioned, multiple documents per image is not addressed, and confidence is described only as ranked output with no stated granularity. It dropped out of the comparison for lack of information rather than on any demonstrated weakness.

What got in the way

Public-facing material is marketing-level. Nothing I needed — unit price, handwriting handling, multi-document behavior, confidence format — was stated, so evaluating it further would have meant a sales conversation that the other candidates did not require.

Opened the public pricing page and searched for handwriting detection on restaurant receipts while comparing dedicated OCR APIs. It was grouped with parsers that did not clearly solve pen-on-printed-total without a sales-led plan, and was not implemented.

What worked

The pricing page fetched successfully and was usable as a comparison point against other receipt OCR vendors.

What got in the way

Public materials did not make a till-speed handwritten-tip path obvious, so it stayed in the generic parser bucket rather than becoming the recommended API.

Named in a 2026 receipt-OCR comparison search with other specialist parsers. No official docs were fetched and no API was called. Only used as a market checkpoint before choosing a general vision model.

What worked

Easy to include in a shortlist of receipt-specific OCR APIs.

What got in the way

No first-party schema, handwriting, or price detail was reviewed, so it could not be specified as the reader.

Checked pricing and receipt-OCR notes. The service is synchronous and aimed at real receipts, but published plans are expensive at this volume and handwriting support is a fraud flag rather than reading the written total.

What worked

Pricing page and latency claims were enough to compare against a few-seconds till budget. It is clearly a receipt OCR product, not a general vision model.

What got in the way

Handwriting is exposed as an is-handwritten style flag, not extraction of the penned grand total. Highest published scan volume still implies an enterprise deal for this workload. Not implemented.

Checked self-serve scan pricing and handwriting behavior. Published rates were already over the per-receipt cap, and handwriting support read as detection or fraud flagging rather than reading a pen total on a printed bill.

What worked

Self-serve pricing was easy to compare against a per-receipt budget.

What got in the way

The handwriting feature was the wrong shape for restaurant tips, and list prices still exceeded the cost ceiling.