r/documentAutomation

Ask questions across your Markdown notes using a fully local Graph RAG engine. Built for Obsidian vaults, works with any folder of Markdown files. Extracts entity-relation triples from wikilinks & YAML frontmatter, retrieves answers via hybrid search (vector + BM25 + temporal). Multilingual. No cloud. Runs on Ollama.

https://github.com/benmaster82/Kwipu

👋 Hey n8n community,

A few of you asked for more detail after my Purchase Order extractor post yesterday. The build looked simple on the surface, but a handful of things bit me along the way. Here are the five that cost me the most time, in case they save you some.

1. Only numbered rows are real articles. The POs had little note lines wedged between items ("2 Box", a location note under a lock, etc). My extraction kept swallowing those into the neighbouring product name, so one row would come out as two items mashed together. The fix wasn't in the workflow at all, it was in the document description I gave the extractor: spell out that only rows with a number in the No. column are real articles, and that unnumbered lines are notes belonging to the row above. That one paragraph cleaned up every merge. Lesson: when a document extraction misbehaves, describe the document better before you touch the nodes.

2. Keep numbers as text until you've checked for empties. Tempting to pull quantity and price straight as numbers. Don't, at least not yet. A missing field comes back as the string "null", and if the field is typed as a number that signal turns into a 0 or a real null and you lose the ability to spot the miss. I keep everything as text, run my checks, then cast to a number afterwards. Clean signal in, clean data out.

3. One helper to catch every flavour of empty. "Empty" is never just one thing. Across the docs I saw real null, the string "null", empty strings, and whitespace. I stopped writing one-off checks and made a single isMissing() helper that catches all of them, then used it everywhere. If a field is missing, the workflow flags it on the form's completion screen with the document name and which field failed, so my friend knows exactly which PO to eyeball instead of trusting the sheet blindly.

4. The Google Sheets checkbox that quietly broke everything. This one nearly broke me. New rows kept landing at the very bottom of the sheet instead of the top empty row. Turns out I'd added a checkbox column with Insert > Tick box, which silently writes a FALSE value into every one of the 1000 cells in the column. The Append node counts those as data, so it always appended below them. If you want checkboxes, add them through Data → Data validation instead, which draws the box without writing a value. Hours lost to a column that looked empty but wasn't.

5. Batch size 1 is not optional here. The extractor node bundles every input item into a single call, so if you hand it two PDFs at once you get one jumbled result. Wrapping it in a Loop Over Items with batch size 1 means each document gets its own clean pass. Small setting, big difference, and easy to miss until your two-file test comes back merged.

The whole thing runs on the easybits extractor node for the actual PDF reading, the rest is stock n8n. If you want to try the Purchase Order extractor yourself, feel free to grab it here:
https://github.com/felix-sattler-easybits/n8n-workflows/blob/c38749a68fd6ea4ae6ebff41789d35cceaacdef1/easybits-purchase-order-extractor-workflow/easybits_purchase_order_extractor_workflow.json

What's the dumbest time-sink you've hit on a build that looked easy? Always happy to hear how other builders tackle this stuff.

Best,
Felix

Hey guys,

I am a law student who has been building Perch AI this in my spare time. When I was surfing I realized most apps are tuned to vibe coding or other dev work. I decided to make an app tuned for writing, research and operative work. It’s available in three formats, all completely free.

If you do a lot of document heavy work, Perch Terminal (Desktop/CLI) for you as it can seamlessly read through 100s of pdfs without blinking.

Genuinely curious if people notice a difference compared to normal AI writing. If not what would you like to see being added.

I built a Telegram bot that answers client questions about my portfolio using n8n, Google Sheets, and Groq AI. No more manual work!

More automations: Join our community: https://go.phonezait.de/

I'm not sure if you all hit this too, but me and a few bookkeepers I know deal with clients handing over a single PDF that's actually a stack of separate invoices. I attach invoices to all bills / expenses on QuickBooks, to back up sales tax information. Splitting those manually is tedious, and the paid tools feel like overkill for this one task.

The free splitters I found cut by page, not by distinct invoice, so I ended up building one that detects the separate invoices and splits them out. It defaults to naming each file Vendor-Date-INV#, and you can rename. No signup, nothing to install.

Full disclosure: I build bookkeeping software (Spendifique), but this splitter is standalone and free, it's not a trial of anything. Sharing in case it saves someone the manual work. Let me know if it breaks on your PDFs or what would make it more useful. Let me know as well if there are any other tools that should be free.
https://www.spendifique.com/invoice-splitter

Patent documents are one of the harder OCR problems out there. A single page can contain merged tables, chemical diagrams, formula blocks, and mixed English/Chinese/Japanese all at once. We've been working on this problem specifically, and after getting to a point where we're happy with the results, we decided to open-source what we built and see what the community thinks.

Here are two tools we use internally.

Hiro-MOSS-OCR is a 0.3B model that outputs structured markup: tables to HTML, formulas to LaTeX, text to Markdown. Trained on 50M+ samples. Ranks #1 on our patent-domain benchmark against all 1.2B models we tested. ~59 QPS on a single RTX 4090 via vLLM.

Hiro-Smart-Doc wraps layout detection (RT-DETR, 25 region categories) and MOSS-OCR into a streaming FastAPI service with an OpenAI-compatible endpoint. Feed it a PDF, image, or Office doc, get back reading-ordered structured content or Markdown.

Both Apache 2.0. Would love feedback from anyone dealing with complex document types where standard OCR falls short.

Thanks!