Looking for early users: AI fills existing Excel templates from PDFs
Hi Indie Hackers — I’m looking for a few early users to try ParseToSheet and tell me where the workflow breaks.
The product is for people who receive PDFs but need the data in their own Excel template, not in a generic converted spreadsheet.
Current workflow:
- Upload one PDF
- Paste or upload your existing Excel-style template
- AI fills the matching cells and columns
- Use chat to fix values, move fields, add or adjust formulas, calculate totals, or reshape the sheet
- Review everything before export
I’m especially interested in feedback from people who deal with invoices, bank statements, purchase orders, bookkeeping templates, or repeated back-office spreadsheets.
Important limitations: it is one PDF at a time right now, scanned PDFs depend on OCR quality, and the output should be reviewed before export.
If this sounds close to a workflow you have, the site is here:
https://parsetosheet.com
What I’d love to learn:
- What kind of PDF + template would you actually test it with?
- Is “fill my existing template” clearer than “PDF to Excel”?
- What would make this useful enough to keep using?
ParseToSheet might be strongest if it starts with invoice / timesheet / PO workflows, not bank statements.Those usually have stable fields, repeated work, fixed output formats, and real cost when the data is entered wrong.
A simple “PDF to Excel” request is probably just a converter use case.
The stronger signal is when someone already has to move PDF data into the same spreadsheet, Access table, CRM, Google Sheet, or reconciliation workflow every week/month.
Found one r/excel example where someone had image-only invoice PDFs used as timesheets. They needed units, rates, descriptions, and unique IDs for payment, but couldn’t copy/paste and Excel’s PDF import didn’t work.
That feels much closer to ParseToSheet’s real pain: OCR + fixed fields + high-risk manual entry.
This is a really useful distinction. I agree that “convert this PDF once” is a weak use case, while “move the same fields into the same workflow every week” is much stronger.
The invoice/timesheet example is especially relevant because the PDFs are image-only, the output fields are predictable, and errors directly affect payment.
I’m going to narrow the initial workflow around invoices, timesheets, and POs rather than leading with generic PDF-to-Excel or bank statements.
My next step is to test:
reusable field mappings
filling an existing spreadsheet template
OCR for image-only PDFs
confidence flags and source references
validation for totals, rates, IDs, and missing fields
One question: in the example you found, did the user need a newly generated table, or did they need the extracted data inserted into an existing payment/reconciliation template? That distinction would help me design the workflow correctly.
Thanks — this gives me a much clearer wedge for ParseToSheet.
Yeah, good question.
This is the Reddit thread I was referring to: [paste Reddit thread link here]
From the post, the user clearly has image-only invoice PDFs that include timesheet data — units, rates, descriptions, and unique IDs — and they need that data to pay people accurately. They also said manual entry is too risky, and Excel’s PDF import doesn’t work because the PDF is image-only.
The part I can’t confirm from the thread is whether they need a newly generated table, or whether they already have a fixed payment / reconciliation template they’re filling today.
But that’s exactly why I thought it was a useful example for you.
Thanks — that context is very helpful.
Even without knowing the exact destination format, the example confirms the stronger problem: this isn’t a one-off PDF conversion. The data is needed for an existing payment workflow, the source is image-only, and extraction errors have real financial consequences.
I’ll use this as a workflow to validate:
OCR for image-only invoices
extraction of units, rates, descriptions, and unique IDs
checks such as units × rate and duplicate IDs
review of uncertain values before payment
support for both a generated table and an existing template
The next thing I need to learn is where users put the extracted data and how often they repeat the process.
Also, could you send the actual Reddit thread link? It looks like the placeholder remained in your message.
Thanks again — this is much closer to the specific use case I should be investigating.
I forgot to paste the actual thread link.
Here it is:
https://www.reddit.com/r/excel/comments/1ix4bgj/what_are_my_options_for_reliably_getting_data/
The positioning that stood out to me wasn't "PDF to Excel"—it was preserving the workflow people already have instead of asking them to adopt a new one.
Replacing a repetitive step is often a much easier sell than replacing the entire process.
Exactly — that’s the direction I’m trying to lean into.
A lot of PDF-to-Excel tools create a new spreadsheet, but the real workflow often already exists: someone has a specific Excel template, formulas, column structure, review process, and downstream handoff.
So the goal is not to replace the whole process. It’s to remove the repetitive “copy data from this PDF into this existing template” step, then let the user review and adjust the sheet before export.
That framing is helpful — I may make “preserve your existing workflow” more central in the landing page copy.
Glad it resonated.
I think there's one implication of that positioning that would be difficult to unpack properly in a thread.
Happy to share it over email if it's useful. What's the best address to reach you on?
victorcong88@gmail.com
Sent over the fuller thought by email.