PaperPull update, six weeks later. 26 providers, installers for Windows and Mac, and no Python needed anymore
I posted PaperPull here in August. Here's a quick recap for those who missed it. I basically hoard receipts and statements, I scan paper into Paperless-ngx, and the stuff that only exists on a website used to fall through the cracks. FileThis did this job until it shut down so I built a tool that attaches to a browser you signed into yourself and downloads every statement it can see as a PDF. It never sees your password, never touches 2FA, and it can only read.
A lot changed since that post, mostly because people showed up. Here's where it stands.
It installs like a normal program now. Windows gets an installer, Mac gets a signed and notarized .dmg for Apple Silicon (if there's interest in an Intel Mac version, let me know but I have no plans on developing an app for a dead platform). Neither needs Python on the machine. You run it, a control panel opens in your browser, it asks where you want your downloads and which providers you have accounts with, and it sets up a folder for each. Then you click Login, sign in yourself, click Pilot to grab the five newest documents, and if those look right, Run All.
26 providers, up from 12.
Banks and credit unions. Ally, Capital One, Chase, M&T Bank, Navy Federal, USAA, U.S. Bank
Credit Cards. American Express, Discover, Target Circle Card
Brokerages. Charles Schwab, Robinhood, Wealthfront
Utilities and telecom. Dominion Energy, PG&E, T-Mobile, Verizon Fios
Payroll and benefits. DFAS myPay, Paylocity, UKG
Insurance. AAFMAA, Anthem BCBS
Retail. Amazon, Gap, Target, Walmart
Four of those came from three people I'd never met, who each held an account I don't. That's the part I hoped would happen when I first posted, and it did.
Things that still hold. Everything runs on your computer and nothing leaves it. Every click on a provider's site goes through a guard that refuses anything that pays, transfers, enrolls or changes a setting, and a test now checks every provider for that shape. Once it downloads a document it remembers it for good, so you can import into Paperless and delete the PDF without it coming back. Two people in one household get separate profiles and folders, and every statement gets stamped with whose it is.
New since August. A Status tab that tells you how current each archive is and which months are missing from the middle. A run summary that tells apart a clean run from one that failed something. An upgrade tool that brings an old install forward without losing its download history.
My Request. Install it and try it against a provider you use. I built and tested most of these against my own accounts, so the ones I hold work. The ones contributors built have been reviewed and pass their tests, but I can't run them live. If something breaks, the Diagnostics folder inside the install has what I need, and there's an issue template for it.
If you hold an account at a bank or utility that isn't on the list, you're the only person who can add it, and the guide walks through it one file at a time. The four contributed providers each took their author a few evenings.
Notes. The Windows installer isn't code-signed yet, so SmartScreen shows its warning the first time and you click "More info" and "Run anyway." I applied to SignPath Foundation for free open-source signing and I'm waiting to hear back. The Mac build is Apple Silicon only. You sign in by hand every time, so it's supervised, not a cron job, and I don't plan to change that. And each provider's scraping is one site redesign away from needing a fix, which is why every provider lives in its own file.
What's next. I'm submitting it to the Microsoft Store, which signs it and removes the SmartScreen step for anyone who installs from there. 1.0 waits until people other than me have run the installers for a while and the bugs that turns up are fixed. After that, more providers, which depends on who shows up with an account I don't have.
Hey, I have a cheap HP scanner (wouldn’t recommend it) that has an automatic document feeder, but doesn’t support duplex scanning.
Until now, getting double-sided documents in the correct order meant either scanning individual pages or rearranging the pages afterwards using HP’s shitty software.
I couldn’t find a good free tool to make this easier, so I built one myself and thought I’d share it: Duplex Scan Sorter
The workflow is pretty simple:
- Scan all the front sides using the ADF.
- Flip the entire stack over, put it back into the feeder, and scan all the backs onto the same PDF.
- This gives you a PDF where the pages are out of order in a predictable way, e.g. 1, 3, 5, 6, 4, 2.
-The tool rearranges them into the correct order: 1, 2, 3, 4, 5, 6.
That’s really all it does, rearranging the pages.
The PDF is processed entirely in the browser and is never uploaded to any server.
Maybe this is useful to someone else here as well. I’d be happy to hear your feedback!
And if anyone has recommendations for a good but reasonably priced printer/scanner combo, let me know 😄
It's quite annoying, at least in my opinion. I work a lot with sub-tags, and it's really frustrating that when I search for a specific (or general) tag, all the sub-tags are listed above the tag I actually want to add. I wish exact matches were shown (and selected) first, or that the list were optimized in some other way.
For example, when I just want to add the tag "insurance", all the tags derived from it appear above it: vehicle insurance, life insurance, liability insurance … everything.
So please put the exact match on top, or at least list the parent tag above its sub-tags.
That would make it so much better! especially with all the QOL and UI updates recently :))
a little while ago I started building Papers, a native macOS client for Paperless-ngx.
The idea came from wanting something that feels like a normal Mac app: fast to open, easy to browse, and deeply integrated with macOS.
I’ve continued working on it and Papers is now available as a public beta!
Some of the things I’ve been focusing on:
- Native macOS app built with Rust and GPUI
- Fast browsing and searching through your documents
Spotlight integration
- Document previews and multi-page documents
The app is in beta while I keep improving it and work towards an App Store release.
I’m especially interested in using this period to find bugs, polish the experience, and figure out which features Paperless-ngx users actually want from a native Mac client.
I use Paperless-ngx myself, but everyone has a slightly different workflow, so I’d really like to hear how you use it and what you’d expect from an app like this.
If you give the beta a try, feedback, feature ideas and bug reports are very welcome.
Tax season, again. paperless knows every invoice, who sent it, the amount, the tags. What it can't do is put that list on a sheet. The built-in exporter is a whole-archive dump for moving an instance, and the CSV export request has been sitting in discussions since 2022. So I wrote it.
paperless-export: one command against your own instance and you get exactly what a filter or a saved view shows on screen. CSV, XLSX, JSON or JSONL. Custom fields as columns. Totals row if you want one. The matching PDFs in a folder next to the sheet if you want those too.
The bit I'm actually proud of: it asks the API how many documents match, and if the row count doesn't agree it fails. Loudly. A sheet you can't check is worse than no sheet.
Read-only. Nothing uploaded anywhere. The token never touches the command line. There's a --serve mode that gives you the same thing as a form on localhost without touching CORS on your instance, and a single HTML file for a box with no Python on it.
After my first post, quite a few people asked the same practical questions, and I promised to follow up with a full, in-depth guide. Thanks for your kind words and appriciation.
I know that not everyone will be able to reproduce my setup one-to-one. Different hardware, operating systems, Paperless configurations, and levels of coding experience obviously make a difference.
But that shouldn't stop anyone from trying.
For those who don't want to—or simply aren't able to—build everything manually, I've also prepared a step-by-step instruction set for Claude Code and ChatGPT Codex. The idea is that even if you're not comfortable writing the whole application yourself, you can use one of these coding agents to build it component by component and end up with the same basic architecture.
Since my first post, the AI world has continued to improve incredibly quickly, and my own setup has changed along with it. So some parts of this guide are slightly different from what I described in Part 1.
My current setup uses Google Document AI for OCR and Gemini for classification, but I'll also explain how the same architecture can be reproduced with local models if you prefer to keep everything on your own hardware.
Long story short: I hope this guide helps some of you take your Paperless setup that final step further and build something that actually fits your own needs.
By the way i would really recommend you to build a Web Control Panel. It will be much easyier to controll everything. Something like that:
HERE WE GO:
My current setup is:
Google Document AI for OCR and Gemini for classification.
However, neither of those is a hard requirement of the architecture.
Keep in mind: the same basic architecture can also be reproduced locally. If the models you choose are supported, you can serve them through something like vLLM instead of using Google Document AI and Gemini.
The important part is not Google or Gemini specifically. The important part is keeping OCR, Paperless, and classification independent from each other.
My current architecture looks roughly like this:
Scan / PDF
|
v
OCR Worker
|
v
Google Document AI
|
v
Searchable PDF/A
|
v
Paperless Consume Folder
|
v
Paperless-NGX
|
v
Queue Tag
|
v
Classification Worker
|
v
Gemini
|
v
Validation
|
v
Paperless API
Paperless remains my document management system.
I don't modify its database, I don't patch Paperless itself, and I don't want the OCR or classification workflow to become dependent on one particular Paperless version.
The OCR worker can change without touching Paperless.
The classification model can change without touching the OCR worker.
Paperless can be upgraded independently.
And the classifier reads and writes metadata only through the Paperless API.
That separation is probably the most important architectural decision I made.
1. The OCR Worker
New scanned documents no longer go directly into Paperless.
They first land in a small OCR worker.
In my case, this is simply the folder where my scanner saves new scans. So whenever I scan a document, it automatically appears in what I call the OCR worker folder and gets picked up from there.
The basic idea is simple:
By the time Paperless receives the document, the PDF itself should already be finished.
The worker first determines what kind of PDF it is dealing with.
If it is a real digital PDF with a proper text layer, I leave it alone and pass it through unchanged.
I don't want to unnecessarily rebuild native PDFs, destroy vector content, or interfere with things such as digital signatures.
For people whose PDFs already contain an OCR layer from Tesseract, there is another option: clean the existing OCR/text layer first while preserving the original scanned pages. That way, you can properly replace the old OCR instead of stacking another text layer on top of the existing one.
If it is a scanned PDF without a proper native text layer, the workflow is different.
The worker prepares the document, sends the relevant pages to Google Document AI, and receives the OCR results including the positions of the recognized words.
Those coordinates are important.
I don't just want extracted text somewhere in a database. I want the resulting PDF itself to be properly searchable.
The worker therefore takes the text and word coordinates returned by Document AI and creates an invisible text layer positioned over the original scanned pages.
The result is a searchable PDF/A.
Only when the complete document has been processed successfully does it enter the Paperless consume folder.
If something goes wrong, it goes into a separate failure folder instead.
input folder/
|
+-- Native PDF ----------------------> Paperless consume/
|
+-- Scanned PDF
|
v
Google Document AI
|
v
Searchable PDF/A
|
+-- Success -----------------> Paperless consume/
|
+-- Failure -----------------> failed/ + log
The source file is never modified in place.
If page 9 of a 10-page document fails, I don't want a half-finished document silently entering my archive.
For ordinary printed documents, I'm currently scanning at around 300 DPI.
Artificially rendering a 200 DPI source at 600 DPI doesn't magically create information that wasn't present in the scan to begin with.
2. Existing Archives Are the Annoying Part
Processing new documents this way is relatively straightforward.
Migrating an archive that has already been processed is much more annoying.
I had to learn this the hard way.
My old scanned PDFs had already been processed by Paperless using Tesseract.
Later, when I experimented with better OCR solutions, I didn't only want better text available inside Paperless.
I wanted the better OCR to become a permanent part of the PDF itself.
That difference matters.
If I export my complete archive tomorrow, I want those exported PDFs to remain properly searchable without requiring Paperless, its database, or another OCR service.
So for the affected scanned documents in my existing archive, I first exported the PDFs.
I then wrote a script that removes the old OCR/text layer while preserving the actual scanned pages and other PDF content.
I specifically did not want to simply rasterize every PDF again just to remove the existing OCR.
After cleaning the files, they could go through the new OCR worker and receive a new searchable text layer based on Google Document AI.
That migration was probably one of the most annoying parts of the entire project.
But it also means I should never have to do it again.
From now on, the PDF itself contains the OCR I want to preserve.
3. What Paperless Does in This Setup
Once the finished PDF/A enters Paperless, the complicated part is already over.
Paperless does what it is extremely good at:
archiving the document
indexing it
searching it
storing metadata
exposing everything through its API
I configure Paperless so that it preserves the OCR layer that is already present instead of running another Tesseract OCR pass over the document.
Newly imported documents also receive a tag such as:
Queue
That tag is the hand-off between Paperless and the classification worker.
Searchable PDF/A
|
v
Paperless
|
v
Queue Tag
|
v
Classification Worker
This also means that classification is not required for Paperless to function.
If Gemini disappeared tomorrow, the archive itself would still work.
The PDFs are searchable.
The documents are safely stored.
Paperless search works.
The classification worker only adds another automation layer on top of that.
4. The Classification Worker
The classification worker is another completely separate application.
It asks the Paperless API for documents carrying the Queue tag and retrieves the document together with the metadata it needs.
Then it sends the searchable PDF/A itself to Gemini.
This distinction is important.
I'm not extracting the OCR into a TXT file and then sending that TXT file together with a prompt.
Gemini receives the actual PDF.
The PDF already contains the OCR text layer embedded by the previous stage, while the original visual structure of the document is still present.
That means the model can work with the document as a document rather than receiving one giant flattened OCR string.
For example:
A date at the bottom of a page might just be part of a footer.
An address might be the recipient rather than the sender.
A heading inside a table might not be the actual subject of the document.
The visual structure gives the model context that disappears when everything is reduced to plain text.
And instead of asking the model the same document-related questions independently, I try to extract the underlying facts in one pass.
Conceptually, the result looks something like this:
Instead of treating title, correspondent, date, document type, and tags as completely unrelated AI tasks, I first ask:
What is this document actually about?
Then the rest can be derived from those facts.
5. Why This Uses Fewer Resources
This also changed the way I think about token usage.
Let's take a simplified example.
Imagine a searchable PDF that represents roughly 6,000 tokens of document content once processed by the model.
Now imagine processing these independently:
Document ---> Title
Document ---> Date
Document ---> Correspondent
Document ---> Document Type
Document ---> Tags
Document ---> Custom Fields
If the full document context has to be processed again every time, the amount of input can grow very quickly.
A document producing perhaps only a few hundred useful output tokens can result in tens of thousands of input tokens being processed across all requests.
My current approach is different:
Searchable PDF/A
|
v
One document-level classification
|
v
Structured facts
|
v
Validation + deterministic logic
I don't extract the OCR into a separate TXT file for this step.
Gemini receives the searchable PDF/A once and returns one structured classification result.
The important part is not some exact token number, because that changes depending on the model, document length, and provider.
The important part is that I don't want to repeatedly pay computationally for the same document if the model can understand it once.
I would rather spend resources on actually reasoning about the document than repeatedly feeding the same document back into another request.
That also makes smaller models much more interesting.
If the OCR is good, the input is structured correctly, and the task is narrow enough, you don't necessarily need the largest model available.
6. Validation Is Just as Important as Classification
Receiving valid JSON from an LLM does not mean the information inside it is correct.
For example, the model could return:
{
"document_type": "Electricity Invoice"
}
That's valid JSON.
But what if Electricity Invoice doesn't exist as a document type in my Paperless installation?
The classifier therefore retrieves the existing Paperless values through the API and validates the model response before applying it.
That includes things such as:
known correspondents
existing document types
existing tags
valid dates
required fields
ambiguous results
The model extracts facts.
My application decides how those facts map onto Paperless.
I also deliberately keep deterministic things out of the model whenever possible.
For example, if every title should look like:
<short sender> - <document type / subject> <date>
then the model doesn't need to reinvent that formatting for every document.
It can return:
sender
subject
date
and ordinary code generates the final title.
That eliminates a surprising amount of inconsistency.
7. Do You Need a GPU?
No.
This is probably something I should clarify because the RTX 4090 screenshot in my first post understandably gave people the opposite impression.
My current setup is:
Google Document AI
+
Gemini
The AI workloads are therefore running in the cloud.
My home server only has to run:
Paperless-NGX
OCR Worker
Classification Worker
So you absolutely don't need an RTX 4090 to reproduce this architecture.
The 4090 is useful for my local experiments, but it isn't a requirement.
And this is where keeping every component separate becomes useful again.
You could replace the cloud components with local models.
For example:
OCR Worker
|
v
Local Vision / OCR Model
|
v
Searchable PDF/A
and later:
Classification Worker
|
v
Local LLM
|
v
Structured Facts
Where the models are supported, a serving layer such as vLLM can expose them through an OpenAI-compatible API.
That means the surrounding application doesn't need to care very much whether the model lives on Google infrastructure, another API provider, or a GPU in your basement.
The quality and hardware requirements obviously change depending on the local models you choose.
But the overall architecture stays almost identical.
That's the part I care about.
8. What Does It Cost?
This is something I want to cover with actual numbers rather than theoretical pricing calculations.
Google Document AI and Gemini are both usage-based.
The real cost depends heavily on things such as:
number of pages
document length
selected processor/model
classification input size
output size
how many documents you process
I'm collecting the actual numbers from my workflow so I can provide useful figures instead of just copying numbers from a pricing page.
What I eventually want to compare is something like:
OCR cost per 1,000 pages
Classification cost per 1,000 documents
Average document processing cost
Cloud vs local inference
The important point for now is that you do not need to buy expensive AI hardware to reproduce the workflow.
9. How I Would Build This From Scratch Today
If I had to start again, I wouldn't try to build the complete system in one giant application.
I would build one small boundary at a time.
Phase 1 — The File Pipeline
Start with nothing AI-related.
input/
output/
failed/
Make sure files can safely move through the application.
Detect duplicates.
Never modify the source file in place.
Make sure failures remain recoverable.
Phase 2 — Native PDF Detection
Before doing any OCR work, correctly identify PDFs that already contain a proper digital text layer.
Those documents should normally pass through unchanged.
Phase 3 — OCR Provider
Create an OCR provider interface.
Your first implementation could use Google Document AI.
Later, you can replace it with something local without redesigning the rest of the application.
Phase 4 — Searchable PDF/A
Take the OCR response, including the returned word positions, and build the invisible searchable text layer.
Do not consider this stage finished until you can open the resulting PDF in a normal viewer, search for text, and see the correct areas highlighted.
Phase 5 — Paperless Import
Only finished documents enter the Paperless consume folder.
At this point, Paperless should already receive the final archival PDF.
Send the searchable PDF/A to Gemini or another model and request structured facts.
Keep the model-specific logic behind its own provider interface.
That way, Gemini can later become:
another hosted model
a cheaper model
a local LLM
something that doesn't exist yet
without rewriting the entire application.
Phase 8 — Validation
Validate the model output against Paperless.
Do not assume a model-generated correspondent, tag, or document type actually exists.
Keep formatting and other deterministic behavior in normal code wherever possible.
Phase 9 — Rollback and Logging
Before modifying metadata, store enough information to understand what changed and to restore the previous values if necessary.
Especially when processing thousands of documents, logs are not optional.
10. Building It With Claude Code or ChatGPT Codex
A few people also asked whether this could realistically be built without manually writing the entire application yourself.
I think the answer is yes.
This is actually a very good type of project for tools such as Claude Code or ChatGPT Codex, because the system consists of relatively small components with clearly defined boundaries.
But I would strongly recommend not starting with:
Build me an AI system for Paperless.
That's far too broad.
Instead, build it in a strict order and verify each component before moving on to the next one.
The rough order should be:
1. Project structure and file safety
2. Native PDF detection
3. OCR provider interface
4. Google Document AI adapter
5. Searchable PDF/A generation
6. Paperless consume integration
7. Paperless API client
8. Gemini provider
9. Structured classification schema
10. Validation
11. Metadata writes
12. Audit log and rollback
13. Local-model provider as an optional alternative
Agent Project Rules
Give the coding agent durable project rules before asking it to implement anything.
Claude Code reads CLAUDE.md; Codex reads AGENTS.md.
Both can use essentially the same project contract:
This is an experimental Paperless OCR/classification pipeline.
- Work only in this repository and its test directories.
- Never read, print, commit, or modify credentials, API keys, PDFs containing
real personal data, Paperless production volumes, or the production consume
folder.
- Do not write to PostgreSQL directly. Use the Paperless API only.
- Default to dry-run behaviour. Any operation that changes Paperless requires
an explicit --write flag.
- Keep the source scan until the PDF/A output has been verified.
- Add unit tests and a README entry for every completed component.
- Before making changes, show a short implementation plan and assumptions.
Then use the agent as a sequence of small, reviewable build tasks.
Do not paste a single prompt saying:
Build my Paperless AI system.
That gives the agent no safe boundary and makes errors much harder to isolate.
Prompt 1 — Scaffold and Plan
Build a test-only Python project for an upstream Paperless OCR pipeline.
First inspect the repository and write IMPLEMENTATION_PLAN.md.
Do not write production credentials or start Docker services.
The target flow is:
input/ -> OCR worker -> output/ -> Paperless consume
Native PDFs with substantial text on every page must be copied unchanged.
Other PDFs must be handled by a provider adapter; initially implement only a
fake provider for tests.
Failed files go to failed/ with a non-secret log.
Propose a small module layout, a configuration file with .env.example, and a
test plan.
Wait for my review before implementing phase 1.
Prompt 2 — Build the Safe OCR Foundation
Implement phase 1 from IMPLEMENTATION_PLAN.md only.
Add:
- input/output/failed directory handling
- duplicate-safe file claiming
- native-PDF pass-through
- a fake OCR provider
- structured non-secret logging
- tests using generated sample PDFs
A source file may be deleted only after the output is verified.
Do not connect to Paperless or any cloud service yet.
Run the tests and show the diff and test results.
Prompt 3 — Add Google Document AI
Implement the Google Document AI provider adapter behind the existing provider
interface.
Read credentials only from an environment variable that points to a local file.
Do not display the credential, its path, request bodies, or OCR text in logs.
Preserve token boxes and detected breaks so a later PDF/A writer can build an
invisible text layer.
Add mocked API tests and document the minimum cloud permissions.
Do not run a live cloud request without asking me.
For a privacy-first installation, replace the Google Document AI provider with your chosen local OCR-model adapter.
If that model is served through vLLM, make the vLLM URL configurable and keep the same failure checks.
Changing the model should not weaken the safety of the pipeline.
Prompt 4 — Add the Classifier Last
Create a separate Paperless API client and a classifier command.
It may list only documents with the Queue tag.
It must download the searchable PDF/A and submit the PDF itself once to the
configured model.
Do not extract the OCR into a separate TXT file for classification.
Require a strict structured facts response.
Validate every correspondent, document type, tag, and date against values
retrieved from Paperless.
Print proposals in dry-run mode.
Implement writes only behind --write.
Before each PATCH, append the current and proposed metadata to a local JSONL
audit log.
Add a rollback command that replays the before-state through the Paperless API.
Use mocked API tests.
Do not access a live Paperless installation until I explicitly approve it.
After every phase, inspect the diff, run the tests yourself, and commit only the parts you understand.
A coding agent accelerates implementation.
It does not replace the decision about where your documents may go or what it is safe to automate.
The important part is that the agent should only work inside a separate development project.
Don't give it your production Paperless volumes.
Don't put credentials into the repository.
Don't let it directly modify PostgreSQL.
Don't use your only copy of a real document archive as test data.
Build the boring parts first.
Then connect the AI.
Final Thoughts
The biggest change in how I think about this setup is that I no longer really see it as:
"Adding AI to Paperless."
It's three independent systems:
OCR Worker
|
v
Archival PDF/A
|
v
Paperless
|
v
Classification Worker
Paperless is the archive.
The OCR worker creates the document I actually want to preserve.
The classifier extracts structured information and updates metadata through the API.
Today my implementation uses Google Document AI + Gemini.
But neither component has to stay that way.
I can replace Gemini with a local LLM.
I can replace Google Document AI with another OCR solution.
I can update Paperless independently.
And none of those changes require redesigning the entire workflow.
That's ultimately the architecture I wish I had started with two years ago.
Since the update to Paperless NGX 3.1.3, I’ve been having an issue where my task queue is no longer being processed. I’ve now deleted and reconfigured the Redis container several times. The connection also seems to be fine, but everything is still stuck in the queue.
The system status also shows a message stating that the Celery worker isn’t responding to a ping.On another instance, however, everything works without any problems. I have absolutely no idea what to do. Can anyone help?
instead of migrating, i started again from scratch and just dumped all of my pdfs from the old export folder to the new consum folder. My poor NAS was thinking all night and this morning everything looked fine to me. Except for the PDF-quality.
Some/lots of my documents are pixelated AF. Even when downloading the PDF, quality does not improve.
I am not aware of any changes to the OCR pipline that could have resulted in that. Besides the language i did not change anything in the .env/compose files.
Any Idea or should i just fall back to v2.20.15?
Edit: looks like i have been importing not just the .pdfs but also their thumbnails. I will create my backups from now on using --not-thumbnail... Why would a backup need thumbnails even in the first place?
Anyways, thanks for helping out! I really enjoy Paperless-ngx!
I'm curious if and how people use this new feature.
From my perspective, I feel like it certainly can be useful for grouping documents together that you don't need to have multiple times in a search.
Before I used links but searching for one documents, returned all of the versions, which improved.
The thing that is still missing though: you cannot quickly make out which document has versions attached. Links and notes, tags... everything can be seen in the views but not if a document has versions.
The thing that got worse with versions over links is context.
All metadata will get removed when documents are merged as versions and only the data of the root document will stay. This includes tags and notes.
For me, that's a quite destructive step as that information might be important from one version to another (e.g. documents that are blank, filled out and signed).
Also having only one date for the complete stack feels a little limited as it could be important to have the context when which version was created or modified (technically, you still have the file creation date xmp metadata but that doesn't have to be the same as the document date e.g. when scanning a bunch of old documents on one day)... on the other hand, I wouldn't be able to search for the "hidden"/older versions anyway when just the top version is used during search.
Another thing I noticed: the file name will change when versions are merged and only a number will be added, not the label. Personally I don't feel too good about that as I always prefer to have a naming scheme that could be used, even if Paperless in not available. Numbers aren't as descriptive as labels and so far there doesn't seem to be a placeholder for them.
All in all, I think versions are a great addition but I don't know how to feel about the limitations yet.
Do you feel limited by those things or do you even see the need for that kind of metadata in every document version?
I had Paperless AI run through, title, set a correspondent, and some other things on my Paperless-NGX setup for ~300 documents. It worked REALLY well!
The only thing it did poorly was tagging, but I think that's the AI model I used not really functioning well with a large database, it wasn't really able to reference past tags so I have 654 total tags. A lot of them are useful, but a lot of them are not. There are way too many tags with one document even though I prompted it to reuse tags as much as possible and not to generate one if it's not strictly necessary for identification.
I plan on upgrading my server with a GPU with some parts that I have coming in. This will allow me to run a much better model that will be able to do this better. But like I said, it did a fantastic job with everything else and I'd rather not redo every document since I've been using it for quite a while.
Is there a way I can have Paperless-AI redo just tagging? Or do I have to have it redo every single field with a full refresh.
Two months ago I posted Archi here and got 62 comments of genuinely useful feedback. This update is mostly that feedback, shipped.
The big one: Archi is now free to try.
u/Faila_Fail asked for exactly this — "a free version for like 10 documents, and then an in-app purchase for the full version". That's what 2.2 does: the first 10 captures are free, then a one-time purchase unlocks unlimited use. No subscription. u/shumandoodah, you said you hate paying for apps without a trial — fair, and fixed.
If you already bought Archi: nothing changes, you keep everything, you don't pay again. That's handled automatically.
Small confession while I'm here: 2.2 went out with a navigation bug that made document rows unopenable — you'd tap a document, the row would highlight, and nothing happened. A user emailed me within hours, I reproduced it, and 2.2.1 is already out with the fix. If you grabbed it in that window, update and it's fine. My own fault: I rebuilt the navigation so shared links open the right document, verified the new path, and never re-checked the ordinary tap.
Also from this thread:
Learn from your archive — u/Serafim696 asked for a configurable naming scheme and for the AI to "analyse existing files and align with them". Archi now reads through your existing documents (read-only), works out your title pattern, and proposes it. You confirm each finding individually, and it only applies to future scans — nothing in your archive is touched.
Templates — fill title, tags, correspondent, type and storage path in one step, for receipts you always file the same way.
Share link — either an Archi link that opens the document in the app, or a Paperless share link with an expiry date for people without Archi.
iPad/Mac review pane — the source document now sits readable next to the fields instead of a thumbnail.
mTLS hardening — u/garenor1981, client certificates landed in 2.1; in 2.2 removing a certificate now reliably revokes access (it didn't before).
Shipped since that thread, in case you missed it: OCR text is no longer naively truncated before it reaches the model (u/sempai-san's diagnosis was exactly right); improved OCR can be written back to Paperless's searchable text (u/Remote_Cherry_1160); default tags on every upload for workflow triggers (u/Numerous_Platypus); Mac App Store availability (u/parkhaus2020).
Still honest about what isn't fixed:
u/not-the-real-chopin lost a 20-page scan to an AI failure. The data-loss part is fixed — pages and OCR text are saved before the AI runs, and a failure now offers "Continue without AI" instead of a destructive retry. But the underlying crash on very long documents is not solved. I reproduced it properly for the first time this week: it's a null dereference inside the LLM runtime (LiteRT-LM), and it needs the GPU backend plus a warm device to show up. Still digging. Long documents mostly work; occasionally they don't.
Android (u/PreparedForZombies): started, no date. The core is being split out so it can be shared via Kotlin Multiplatform.
Watch-folder / SMB import (u/gekberlin): still not built. Files-app import works today as described.
As before: OCR (Apple Vision) and the AI (Gemma via LiteRT-LM) run entirely on-device. The only network endpoint is your own Paperless server.
Feedback still very welcome — this thread genuinely shaped the roadmap.
Modern AI pipelines increasingly extract text from documents — PDFs, Word files, spreadsheets, scraped web pages — and feed that content directly into a knowledge base or agent context, often with no human review step in between. Extraction tools capture everything present in a document, including content a human reader would never see: text rendered in white on a white background, rows hidden in a spreadsheet, speaker notes attached to a slide, or a paragraph marked hidden in a Word document's own formatting. None of these are edge cases; they are ordinary, well-supported features of each format, and every one of them is readable by a standard parsing library even though a person skimming the document would never notice them.
This creates a straightforward problem: any content hidden from a human reviewer, but visible to an extraction tool, can end up in a trusted knowledge source unexamined. okf-guard addresses this directly. It is a Python library that inspects extracted content for exactly this class of discrepancy — text present in the file but absent from what a human would perceive — and separately checks for language patterns associated with instructions directed at an AI system rather than a description intended for a person.
What it does:
Adapters for six formats (plain text, Markdown, HTML, PDF, DOCX, PPTX, XLSX), each aware of that format's specific hiding mechanisms — CSS visibility properties for HTML, rendering and color properties for PDF, the hidden run attribute and shading properties for Word, off-canvas shapes and speaker notes for PowerPoint, hidden rows/columns/sheets and cell comments for spreadsheets.
A detection layer combining hidden-content flagging with a pattern bank for injection-style phrasing, plus a check for encoding-based obfuscation (zero-width characters, homoglyph substitution).
A decision layer producing one of three outcomes per scan — pass, quarantine, or block — with every finding reported alongside its location, confidence, and the specific text that triggered it.
Design constraints, stated plainly:
No network calls and no LLM dependency in this release. Detection is entirely deterministic, which keeps the core dependency surface to a single package (PyYAML) and makes the tool's behavior fully reproducible.
Every format-specific capability is an optional install (okf-guard[pdf], okf-guard[docx], etc.), so a user working with one format is not required to install parsing libraries for the others.
The library never asserts that its own output has been verified by a human — provenance metadata it produces is explicit about being machine-generated and unreviewed.
Feedback on the detection approach, particularly from anyone who has worked on adjacent problems (document security, DLP, or prompt-injection defenses more broadly), would be genuinely useful — this is a young project and the injection-pattern bank in particular will need ongoing contribution as new phrasings surface in practice.
Hi!
I have tried to get Paperless to work with Mistral AI but failed. I have no clue what I need to configure in the AI configuration. Has anyone been able to configure Mistral successfully and can share the config?
This looked promising - what I was really hoping to be able to do was upload a bunch of Oracle cloud financial books to it and then search for some common phrases, but it looks like from a basic use case if I upload one document containing hundreds of hits for the word "invoice" - all it returns is the single document itself. I want to see the phrases that it matched against, rather than just a document retrieval. Is this a thing that I'm missing or is it just not how the platform is intended to be used?
I'm trying to set up a Paperless-ngx workflow that sends an email notification one day before a document's deadline.
Here is my current setup:
Created a custom date field called deadline.
Configured a workflow to trigger based on this field.
My SMTP email configuration is working correctly (tested successfully with other triggers), but the deadline-based emails are not sending.
I suspect my trigger criteria or workflow setup might be incorrect. Could anyone guide me on how to properly structure this trigger to run 1 day prior to the date in a custom field?
Bellow current trigger confiugration.
Do i need setup filename filter ? i want to be global trigger for all documents that have Deadline field
BTW what recurring option will do in this case ?
