A convert PDF to Excel app has to rebuild a table nobody ever stored.
A convert PDF to Excel app sounds like a small project. Upload the file, the rows come out, done. It is not small, and the reason is structural: a PDF does not store a table. It stores instructions for painting glyphs at coordinates on a page. Anything that gets rows back out is inferring them from positions, and inference is sometimes wrong. The opposite direction, taking a sheet you already keep and turning it into screens people use, is a different job, covered in Excel to web apps.
This page covers why the table has to be reconstructed and what the three kinds of extraction list at. It also covers what a thousand pages a month really costs, and why most of the finished app is the screen where a human checks the result.
See what a thousand pages costsThe short version
Extraction is a paid API call, and the review screen is the app.
Published list prices put structured table extraction between $10 and $30 per 1,000 pages, and plain text OCR at around $1.50. At a few hundred pages a month that is single figures. Almost nobody abandons this project over the API bill.
Accuracy is what sinks it. A merged cell, a description that wraps onto a second line, a total row that looks like data, a header repeating on page four: each one produces a confident wrong answer. So what you are really building is a PDF to spreadsheet app with a proofreading step in the middle, and that step is where the design work goes.
Why the table has to be rebuilt every time
A PDF page is a drawing. The file carries fonts, glyph positions, line widths and images, written in whatever order the producing program chose. There is no cell, no row index and no column boundary in that model unless somebody deliberately added one. PDF does have an optional tagged structure layer that can express real table semantics, but the invoices, bank statements and lab reports in general circulation were mostly never tagged.
So a parser infers. It clusters text by horizontal position to guess columns, by vertical position to guess rows, and leans on ruling lines where they exist. On one clean bordered table this works very well. On a statement where the description column wraps, or a report with two tables side by side, it starts putting things in the same row that were never related.
That is the whole reason a PDF table extraction app needs a correction step. What comes back from extraction is a best guess with a confidence attached, not a fact. Treat it as a draft and the project is straightforward. Treat it as truth and you ship a spreadsheet with silently shifted numbers, which is worse than shipping nothing.
Three different products get sold as PDF extraction
Before pricing anything, work out which of three jobs you need, because vendors price them separately and the gap between them is large. Plain OCR returns text and word positions. A layout parser returns the document split into blocks, tables among them, with a row and column shape. A form parser returns key and value pairs, which is what you want from a single field on a claim form and not what you want from a 40 row table.
Google Cloud publishes all three on one page. Enterprise Document OCR is free for the first 1,000 pages in a billing cycle and then lists at $1.50 per 1,000. Layout Parser, which includes an initial chunking pass, lists at $10.00 per 1,000. Form Parser lists at $30.00 per 1,000 for the first million pages, then $20.00. Those are processor list prices, and Document AI is meant to be used alongside other Google Cloud products, so the parse will not be the only line on the bill.
The practical read is short. If what you have is a table, pay for table or layout extraction and skip the form parser. If what you have is one number in a box, the form parser earns its triple price. Picking the wrong one is the most common route to concluding that PDF extraction does not work.
What a thousand pages actually costs
Amazon publishes the other half of the comparison. Textract Detect Document Text lists at $0.0015 a page, which is $1.50 per 1,000. AnalyzeDocument with the Tables feature lists at $0.015 a page, so $15.00 per 1,000 for the first million pages a month, dropping to $0.010 a page above that. Those figures are the US West Oregon region and pricing varies by region. New AWS accounts get a three month free tier that includes 100 pages a month on the Tables, Forms and Layout features, which is enough to test with and nowhere near enough to launch on.
Put a real volume in and the shape of the decision changes. Four hundred pages a month through table extraction is about six dollars. Ten thousand pages is about a hundred and fifty. Against per seat desktop converter licences for a team, the API is usually the cheaper answer, and it is the only one of the two that runs inside your own app with nobody sitting at a desktop.
Low volume cases barely register. A warranty tracking app that parses a receipt or two a week spends cents a month on parsing and the rest of its budget on the screens around it. Volume only matters when you have a back catalogue to get through, and the right move there is to batch it once rather than design the whole app around a one off.
Amazon Web Services, Textract pricing
Try it
What the parsing bill actually comes to
List prices published by the two vendors, read in September 2026. Pick how much structure you need, then how many pages a month go through it.
$6.00 a month
That route lists at $15.00 per 1,000 pages and hands back cells with row and column numbers. The API line is rarely what kills this project. The screen where somebody checks the rows is the real cost.
The app is mostly the screen where somebody checks
Sketch the finished thing and it is five steps, of which exactly one is the API call. Pick a file or photograph a page. Send it for extraction. Show the parsed grid. Let someone fix a cell, rejoin a wrapped row, delete a repeated header. Then write the result out as a sheet, or into a table you keep.
Steps three and four are the whole build. A parsed table needs a view that survives twenty columns on a phone: one row at a time with the fields stacked, not a grid you pinch to zoom. Cells the parser was unsure about should be marked, because confidence comes back per cell and hiding it throws away the one piece of information you paid for. Give the person a keyboard path through the flagged cells and the checking takes a minute instead of ten.
You can also scan a document to Excel with the phone camera, and that is the same pipeline with one more failure mode at the front. Capture through a document scanner flow that finds the page edges and flattens the image, then run OCR, then run table logic on the OCR output. A raw angled photograph with a shadow across the middle gives the parser worse coordinates, and worse coordinates mean worse columns. Keep the original image attached to the record so a disputed number can be checked against the paper.
Where the corrected rows go decides how useful any of this is. Exporting an .xlsx and mailing it to yourself is fine once. If the same layout arrives every month, the rows belong in something you can query, which makes this a database mobile app with an import step bolted to the front. Settle that before the first screen, because it changes every screen after it.
What each route to a spreadsheet gives you
| Route | Reads scanned pages | Keeps rows and columns | Runs inside your own app | Published cost per 1,000 pages |
|---|---|---|---|---|
| Retype it by hand | Yes | if you are careful | No | your time |
| Desktop converter software | with an OCR option | usually | No | per seat licence |
| Plain OCR in your app | Yes | No | Yes | $1.50 |
| Table or layout extraction API | Yes | Yes | Yes | $10 to $15 |
| Form parser API | Yes | fields, not a grid | Yes | $30 |
Building one around the documents you actually get
Generic converters are built for generic PDFs. People build their own because their documents are not generic: the same supplier statement every month, the same lab report layout, the same three page form from the same agency. Once the layout is known you can map the columns once and validate against rules you already know. A total that has to reconcile. A date that cannot be in the future. A part number that has to exist in your catalogue. A parse that fails one of those gets refused instead of saved, and a general purpose tool cannot do that, because it does not know your rules.
Newly is an AI app builder. You describe the app you want, including the document layouts and the checks that have to pass, and it writes a real React Native and Expo project you own. It runs that project on a cloud iPhone or Android simulator while it builds. iOS ships through TestFlight and App Store Connect, using your own Apple Developer account. Android goes to Google Play internal testing, or out as a standalone APK with the JavaScript bundled. Plans are $25 a month and there is no free plan. It does not come with a PDF parser: the extraction call is a service you sign up for and pay for yourself. There are no built in payments either, so it is not the tool for selling conversions by the page.
Decide where the extracted rows land before you build any screens. Rows that live only inside the app are a dead end the first time somebody asks about last quarter, and moving them afterwards means rewriting the part of the app you were proudest of.
Questions people ask about converting PDFs to Excel
For the easy case, yes. If the PDF was generated from a spreadsheet and holds one bordered table, an open source text extractor plus your own column clustering can be enough. For scans, tables that run over page breaks, wrapped cells and merged headers, a hosted parser is doing work you would otherwise have to build and keep maintaining.
Describe the documents you actually get
List the layouts that arrive every month, the checks a parse has to survive, and what a correct row looks like. That description is most of the app.
Start building