Every team has a folder where PDFs go to be ignored: supplier invoices, signed offers, a 40-page report someone "will read later". The fix I wanted was boring and specific: drop a file into a Google Drive folder, and a minute later there is a Google Doc next to it that says what the document is, lists the key facts with page numbers, and says whether anyone has to do something.
This post is that workflow for n8n, with the parts that were harder than expected.
Disclosure: I built this actor: the PDF conversion step runs on Document to Markdown on Apify. Prices and the free alternatives are below.
The flow
Google Drive Trigger (new file in "PDF inbox") Webhook (POST {"url": ...})
└──────────────┬──────────────┘
Code: collect { url, name }
↓
HTTP Request: Document to Markdown
↓
IF status = success
├ yes → LLM chain: summarise → Google Docs: create → Google Docs: insert text
└ no → Set: file + error (not charged)
Two entry points feed the same pipeline. The Drive Trigger polls one folder every minute. The webhook takes {"url": "...", "name": "..."} so anything that can make an HTTP call (a mail parser, a form, another workflow) can push documents in.
Why convert to Markdown before the LLM?
You can paste raw PDF text into a model, and for a clean one-column letter it works. Invoices, price lists and reports are mostly tables, and plain text extraction flattens tables into a stream of numbers. The model then has to guess which amount belongs to which line, and that is exactly where summaries get wrong.
Markdown keeps tables as rows and columns and puts a <!-- Page N --> marker before every page. That second part makes the prompt instruction "add the page number for each fact" actually work.
A real run
I tested the conversion step with a one-page sample AWS invoice from the open-source invoice2data test files. The Actor input is exactly what the n8n node sends:
{
"documentUrls": ["https://raw.githubusercontent.com/invoice-x/invoice2data/master/tests/compare/AmazonWebServices.pdf"],
"ocr": "auto",
"includePageBreaks": true
}
Result metadata:
{
"status": "success",
"fileType": "pdf",
"title": "Amazon Web Services Invoice 296664039561",
"pageCount": 1,
"pagesProcessed": 1,
"ocrPages": 0,
"billedPages": 1,
"wordCount": 326
}
The conversion took 0.9 seconds; the whole run, including container start, about 10 seconds. The totals block came back as a proper table:
# Summary
| AWS Service Charges | $4.11 |
| ---------------------- | ----- |
| Charges | $4.11 |
| Credits | $0.00 |
| Tax * | $0.00 |
| Total for this invoice | $4.11 |
And the per-service detail (EC2 $1.87, Glacier $2.22, S3 $0.01, data transfer $0.01) as rows of a second table. That is what you want an LLM to read.
The honest part: the bill-to address lines came out as ## headings, because they are set in a larger font and the converter treats bigger text as headings. Harmless for a summary, but don't treat the headings of an invoice as a reliable outline.
The prompt
The summary step is n8n's Basic LLM Chain with gpt-5-mini (swap in any chat model node):
Write plain text, no Markdown:
1. One sentence: what kind of document this is and who it is from.
2. Key facts as 3-7 short lines starting with '- ': parties, dates,
amounts, deadlines, decisions. Copy numbers exactly. Add the page
number from the <!-- Page N --> markers, e.g. (p. 2).
3. 'Action needed:' followed by what someone has to do, or 'none'.
"Copy numbers exactly" and the page references matter more than any clever wording. If a fact has a page number, you can check it in five seconds.
The Google Doc then gets the summary, a source line (Pages: 1 (OCR: 0), words: 326) and the full Markdown below it, so the doc is searchable in Drive even when the summary missed something.
The part that took longest: Drive links
The Actor runs in the cloud and downloads files by URL. It never sees your Google account. So the Code node turns each new Drive file into a share link (drive.google.com/file/d/<id>/view, or the docs.google.com/... link for native Google Docs, Slides and Sheets), and the Actor converts those into direct downloads.
That only works if the folder is shared as Anyone with the link: Viewer. Drive IDs are long and random, but this is still a real trade-off: for contracts, payroll or health data, don't use a link-shared folder. Use the webhook with expiring links (S3 pre-signed URLs, for example), or run a converter yourself.
DIY alternatives
- MarkItDown (Microsoft, MIT): great for DOCX/PPTX/XLSX, decent for digital PDFs, no OCR out of the box. If you self-host n8n, an Execute Command node calling it is a perfectly good replacement for the HTTP step.
- pdfplumber / pdftotext: fast and free; you build tables and page markers yourself.
- Send the PDF straight to a multimodal model: works for short files, but you pay vision tokens per page and get no reusable text for search.
The hosted route is worth it when you don't want to maintain OCR dependencies on your n8n box, or when documents arrive as URLs anyway.
Cost
- $1.50 per 1,000 pages with a text layer, +$5 per 1,000 for pages that need OCR, up to 25 % less on higher Apify plans.
- Failed downloads and files without text are free.
- 50 one- or two-page invoices a month: about $0.10. My test run: one page, $0.0015.
- Apify's free plan includes $5 a month, about 3,300 text pages.
Add "pages": "1-5" to the input to convert (and pay for) only the first pages of long reports.
Get it
- Workflow JSON and setup guide: https://github.com/ichkifokkus/data-recipes/tree/main/6-pdf-inbox-to-markdown
- Actor: https://apify.com/fast_data_asap/document-to-markdown
Setup takes about ten minutes: an Apify token as a Header Auth credential, Google Drive and Docs, and an LLM credential. Drop one test PDF into the folder before you point a mail rule at it.
Top comments (0)