If you've ever tried to automate data entry from invoices, receipts, or purchase orders, you've probably met one of the classic document parsing tools — DocParser, Parseur, or something like them. They've been around for years, they work, and for a long time they were the best option available. So why build another one?
Because the way those tools work — and the way they charge — was designed around a constraint that no longer exists. ParseDirect is what a document parser looks like when you start from scratch with a large language model that can actually read.
How legacy document parsers work: zones and rules
Traditional parsers are template-based in a very literal, geometric sense. To extract the total from an invoice, you upload a sample document and draw a box — a "zone" or "parsing rule" — around the place where the total appears. The tool records the coordinates: the total lives in the bottom-right region, about 80% down the page. For trickier fields you layer on rules: "take the text after the word ‘Total’", "match this regex", "split on the third comma".
This is a perfectly reasonable design — for software that can't understand what it's looking at. OCR turns pixels into characters, but characters aren't meaning. If the machine can't know what a "total" is, the only thing left to anchor on is where it usually sits on the page.
Where coordinates fall apart
The problem is that zone-based extraction doesn't degrade gracefully. It works right up until it silently doesn't:
- A new vendor shows up. Their invoice puts the total in the top-right instead of the bottom-right. Your zone now captures a purchase order number, or nothing at all. You have to notice the failure, then build and test a whole new template for that vendor — and every vendor after them.
- An existing vendor redesigns their layout. They add a promotional banner, switch invoicing software, or move the address block. Nothing tells you the template broke; you find out when downstream numbers stop making sense.
- The content shifts the layout. A ten-line-item invoice pushes the totals block onto page two. Fixed coordinates have no answer for content that flows.
- The document is a scan or a photo. A slight skew, a coffee stain, a phone photo taken at an angle — geometric anchors get much less reliable, and many legacy tools treat OCR for scanned input as a separate (sometimes separately-priced) step.
Teams end up maintaining dozens or hundreds of per-vendor templates, which is its own quiet operational tax: every template is a little piece of configuration that can rot, and every new document source is a setup project instead of an upload.
The AI-native approach: read the document, not the pixels
ParseDirect doesn't use zones, coordinates, or per-vendor rules. Instead, you describe the fields you want once, in plain language — "invoice number", "vendor name", "total amount due", "line items with description, quantity, and unit price" — and we hand the document to Claude, a frontier large language model, to read semantically.
Semantic reading means the model understands context the way a person skimming the document would. It knows the number next to "Amount Due" is the total even if it's in the top-left. It knows "Bill To" and "Sold To" are different parties. It reads a vendor it has never seen before the same way it reads one it's seen a thousand times — because it's not matching a memorized layout, it's reading.
What that changes in practice:
- One template covers every layout.A single "Invoice" template handles all of your vendors — current and future. A new supplier isn't a re-templating project; it's just another upload.
- Scans and photos are first-class.Claude reads images natively via vision, so a phone photo of a receipt goes through the exact same pipeline as a digital PDF. There's no separate OCR engine to configure or pay extra for.
- The output is structured, validated data. Every extraction is constrained to the exact schema your template defines — the fields you asked for, with the types you asked for — available in the dashboard, as a CSV export, or as JSON from the REST API.
Pricing without the decoder ring
The other thing we wanted to fix wasn't technical at all. Legacy parsing tools tend to price in "credits", and credits rarely map one-to-one onto documents. Multi-page files, scanned documents needing OCR, or "premium" parsing modes can each burn credits at a multiplied rate — so the quota on the pricing page and the number of documents you can actually process are two different numbers, and you only learn the real exchange rate after you've signed up.
ParseDirect prices in pages. A page is a page: a 5-page PDF costs 5 pages, an image costs 1, and a scan costs exactly the same as a born-digital PDF. There are no multipliers, no premium-mode surcharges, and no arithmetic between what the pricing page says and what you get.
The free tier reflects the same philosophy: 50 pages every month, free, forever— not a 14-day trial with a countdown timer. If your volume is small, you may simply never need to pay us, and that's fine.
Is a legacy parser ever the right choice?
Honestly — sometimes. If you process one rigid, never-changing form from a single source, a hand-drawn zone template will do the job. But the moment your documents come from more than a handful of sources, or the layouts aren't under your control, the per-template maintenance model stops scaling and starts costing you engineering time that semantic extraction simply doesn't.
Try it on your ugliest document
The fastest way to evaluate ParseDirect is to feed it the document your current setup struggles with — the crooked scan, the weird vendor, the invoice with the totals on page three. Create a free account, describe your fields, and see what comes back. The first 50 pages each month are on us.