My bookkeeper never asked for any of this. I built it because I am lazy. Laziness, properly weaponized, is the closest thing our profession has to a virtue.
This is part of the Paper Trail series: turning an entire family’s paperwork, from today’s invoices to court files and century-old records, into a system that reads itself. The map of the whole project is the first entry; this post is where the building starts.
The full problem is enormous, and I’ll get to it: medical records across generations, court cases spanning five decades, property files, documents older than a century. None of that is where you start. You start with the paper that hurts every month, company invoices that need to reach the bookkeeper and bills that need to be paid, because a system that isn’t useful in week one is a system you abandon in week three. The rule for this phase was simple: the fastest thing that works, end to end, now. The cathedral comes later.
The fastest thing that works
Paperless-ngx is an open-source document management system, and it earns the “fastest” title honestly. You feed it documents; it runs OCR on them, stores the original next to a searchable text layer, and organizes everything with tags, correspondents, and document types. Crucially for everything that follows, it exposes a full REST API: whatever you can click, you can call.
Here is what made the decision easy: even if I never touched the OCR, the search, or paperless as a database of record, it would still earn its place. Out of the box it stores every original safely, detects duplicate files, polls a mail inbox, swallows anything dropped into a watch folder, and puts all of that behind the API. That is the floor, and the floor alone is worth the deployment.
It also settles a bigger question in advance. Whatever the later phases turn out to need (a vector database, serious OCR, local LLMs, RAG pipelines, a full database of extracted facts), none of it has to live inside paperless. It can sit next to it and talk through the API, while paperless stays exactly what it is: the place where the originals live. The system is upgradeable without being a platform bet.
The deployment is one Docker Compose stack: the paperless web server, PostgreSQL, Redis, Gotenberg (converts office formats to PDF) and Tika (text and metadata extraction for anything that isn’t a clean PDF). It runs on my home server alongside everything else I self-host, and the whole archive is backed up off-site, client-side encrypted; that setup deserves its own post, so here it gets one sentence.
An evening of work, and the archive existed. Empty, but existing. That is the entire point of a bootstrap.
Two doors in
Almost every document arrives through one of two doors, and both were chosen for the same reason: they require almost nothing from me.
The digital door is an email address. A PDF invoice lands in any of our mailboxes; we forward it to a dedicated address; paperless polls that mailbox and consumes whatever shows up. Note what is not happening here: paperless has no access to our primary mailboxes. I considered it (the integration is supported) and decided against it. The forward is one keystroke, and in exchange the system sees only what it is explicitly shown. For an archive that will eventually hold the family’s most sensitive paper, that is the right default: opt-in per document, not standing access.
The paper door is the scanner. It’s a network document scanner that scans straight to a shared folder, which is mounted as the paperless consume directory. Paper goes into the feeder and shows up in the archive; it never touches a computer in between. Choosing that scanner is a story of its own (Linux support narrows the market considerably), and it’s the next post in this series.
There are side doors too, of course: the web UI takes a straight drag-and-drop, and a mobile app turns the phone camera into a “scanner” for the stray paper that shows up nowhere near the real one. They exist and they get used, but they are conveniences. The two doors above carry practically everything, precisely because they ask for nothing.
Coding agents, hired as clerks
Out of the box, paperless gives you storage and search. The part that makes the archive work for me is a set of reusable coding-agent skills built on the paperless API. I use them through multiple coding agents; Claude Code is one of the tools, not the architecture.
Every new document lands with an INBOX tag, and the tag means exactly one thing: this document still needs work. Sometimes that work belongs to the LLM, sometimes to me (a bill to pay, a form to sign); the queue does not care. The skill reads it and does the clerk work: assigns tags and correspondents, writes a sensible title and description, and fills in the metadata. Paperless ships with a useful set of fields out of the box and lets you define custom fields on top, so the agent has real, queryable columns to write into, not just a free-text blob.
The built-in OCR turns out to be a floor as well, not a ceiling. The agents read the PDF or the scan image directly, with their own eyes: when the built-in text layer comes out mangled, the skill runs its own extraction and overwrites the document’s content field with the better version. Nothing ties the archive’s intelligence to the OCR it happened to ship with.
Then the part my month used to be made of: the bookkeeper mail. The skill collects the period’s accounting documents, downloads the PDFs, and drafts the email; the output is a folder holding the mail text and the attachments, ready to go.
I read it, and I press send.
The button I kept
That last sentence is the design, not a limitation. Sending the mail could be automated in five minutes; the skill already does everything up to that point. It is deliberately wired so the LLM cannot send anything directly: it prepares, I approve, I send. One human gate, placed at the exact spot where something leaves the system.
Should this be a mini app, with a review screen and a send button? Probably, one day. For now a folder with the mail text and the PDFs is good enough, and good enough now is the doctrine this entire phase runs on.
This is the same architecture I argue for in commercial systems: give the agent real capability through a controlled interface, record what it does, and keep a human at the gate that matters. Not a human at every step, which kills the point of automation, and not zero humans, which means the first hallucinated invoice goes straight to your bookkeeper with your name on it. The archive earned trust the way an employee would: checkable first, trusted second.
The QR code my bills forgot
One more skill, and the most satisfying one. Serbia runs an instant payment system called IPS (operated by the National Bank of Serbia), and its best everyday feature is the IPS QR code: a standardized code printed on a bill that encodes the payee, account number, amount, payment model and reference number. Any Serbian mobile banking app scans it and pre-fills the entire payment; paying a bill takes seconds.
The catch: plenty of bills still arrive without one. For those, I built a script and a Claude skill that read the extracted bill data and the image of the payment slip, and generate the IPS QR code that should have been printed there in the first place. I point my phone at my own screen, the banking app fills in the payment, done.
Note the boundary holding even here, at the closest point the system gets to money: the skill prints a code. The authorization still happens in my banking app, with my thumb. Same gate, different door.
A recent favorite from that same flow. The United States and Serbia have no double-taxation treaty, so every payment to a US company comes with a 20% withholding tax, my Claude subscription included. A withholding tax under which nothing is withheld: the US side charges full price, so the base gets grossed up and the “withheld” part materializes on top, out of my pocket. After every charge, the bookkeeper sends a payment order for it. The bank takes its cut too: an 8.5% conversion fee on a payment that leaves in dollars and arrives in dollars. I asked the archive what one of those orders even was. It cross-referenced the bank statement, found the matching Claude charge, explained the math down to the dinar, and offered to generate the IPS QR to pay it.
Savor the loop: the subscription gets taxed, the tax gets explained by the thing being taxed, and the payment code rolls out of the same machine. Everyone in this arrangement is automated except the people who invented it, and they should have been automated first.
I will have my revenge, in this tax haven or the next.
Asking the archive from a phone
None of this needs me at a desk. My phone and my desktop share a Tailscale network: from the phone I connect to the PC, the PC starts Claude Code, and Claude Code talks to paperless with every skill described above. That chain sounds mundane and feels anything but, because at the end of it I can type: “find my employment contract, and tell me whether I am allowed to do X.” The agent finds the contract, reads the clauses, and answers, pointing back at the exact document.
No vector database, no RAG pipeline, no advanced machinery: full documents plus an LLM that reads them already cover a surprising share of real questions. The advanced machinery comes later in this series, when the archive grows big enough to demand it.
It stretches further: ask it to pull the electricity consumption out of a year of utility bills and draw a chart, and it does, today, and does it well. What would make answers like that sharper still is better OCR than the built-in one, and that is exactly where this system is headed next. The direction is set: the archive is something I talk to, not something I browse.
Small archive, real production
Is this a grand archive yet? No. It’s a few hundred megabytes of company paperwork, and it has been in daily production use since the first week, which beats any amount of grand. The bookkeeper gets a tidier mail than the one I used to assemble by hand. The bills get paid faster than when I typed account numbers myself. Every document that enters the house now has exactly one place to be.
The rest of the plan grows from here, area by area: serious scanning hardware, medical records with local models, handwritten documents, those fifty-year court files, and eventually paper older than anyone alive. The system will need to get much smarter, but it already does the reading.
Laziness got automated. Judgment didn’t.
The Paper Trail series
- Paper Trail - the map of the whole project
- Paper Trail: Bootstrapping a Family Archive - this post
- Paper Trail: Phone, Flatbed, or a Real Document Scanner - the hardware door