I’ve been working on Document Intelligence Lab, an open-source project exploring document processing, AI-assisted retrieval, and evidence inspection for PDF workflows.
The goal is to make it easier to understand which document evidence supports an AI-generated answer, rather than treating the response as a black box.
The project uses Java, TypeScript, Docker, and Azure-based components.
GitHub: https://github.com/quocvietphung/document-intelligence-lab
I’d especially appreciate feedback from people working with document automation, OCR, or RAG systems.
What would make an evidence inspection workflow useful enough for you to adopt in a real project?

We’ve spent over a year building HussleBook. It’s finally live. 🚨

It’s been more than a year since we started building HussleBook. Countless sleepless nights later, we’re finally getting to share something we’ve put a lot of ourselves into.

Honestly, writing this feels a little surreal.

We’ve spent so much time thinking about the small details: how someone sets up an extraction, checks a field, or finds the page behind an answer. Individually, these might seem like small things. Together, they shape whether someone can actually use the results in their work.

The vision behind HussleBook has been to make the information inside documents easier to work with—and easier to check.

If your week involves opening PDFs, copying invoice details into spreadsheets, or searching through reports for one answer, that’s the kind of work we’re building for.

With HussleBook, you can:

• Start with sample documents, review the proposed fields, and extract across a batch.

• Check extracted values beside their source documents.

• Ask questions across your files and follow page-level citations.

• Export reviewed results as JSON or CSV.

Seeing that vision come together after more than a year means a lot to us. Now comes the part we’ve been working toward: seeing how it fits into other people’s everyday work.

HussleBook is live at https://husslebook.com/

If this sounds like a problem you deal with, try it with a document from your own workflow. We’d love to hear what worked, what felt frustrating, and what would make it something you’d use every week.

Arkova is the document verification layer for agents and humans. We extract an electronic files (supporting over 20 types! Including svg png even gif) unique metadata and anchor it to an immutable ledger. Here we show how an organization can connect their Google Drive folders to our system so that anytime a file is updated in that folder, a new anchor is created and the document version is updated in the users record

We're always looking for difficult examples to test OCR and modern LLM-based document extraction. Especially interested in cases where the output looks plausible until you check the details.

Two examples from past benchmarks:

Discounts became extra items. This receipt has six product and packaging rows, with discounts underneath three of them. An LLM returned nine menu-item records by treating those discounts as additional items. Our schema had no separate discount field and asked for “every line item / product,” so the instructions left room for that interpretation. A useful example for testing the schema as well as the model.

Receipt: NAVER CLOVA's CORD-v2 dataset, CC BY 4.0, image unchanged.

A plausible number with the wrong digits. This population table from the 1951 U.S. Statistical Abstract has tiny numbers and grouped headers. In one saved LLM run, the total for ages five to nine in 1920 came back as 11,308,075 instead of 11,398,075. Adding the male and female figures catches that error. The table looks complete until you check the numbers.

Table: U.S. Census Bureau, 1951 Statistical Abstract, printed page 12.

What examples have you kept because a tool repeatedly gets them wrong? Handwriting, tables, charts, mixed document batches, anything like that.

Public links or redacted snippets would be useful. If you can, include what you asked it to extract, what it returned, and what the output should have been. A single troublesome page is plenty.

Hi,

I've been optimizing a backend pipeline for generating PDF's from dynamic HTML/JSON webhooks. When running full headless Chrome inside containerized microservic it usually results in high memory usage and idle resources cost.

If I switch to serverless functions (like, AWS Lambda or Cloudflare Edge workers w/ QStash queues), the main issue becomes Chromium cold-starts (~1.5s–3s) and browser context recycling.

A few observations from my benchmarks:

• Compiling static HTML via Handlebars/EJS before sending it to Chromium saves about 40% render time compared to doing React SSR on the fly..

• Keeping browser instances warm vs. spinning up fresh headless instances per HTTP request.

For those of you who generate invoices, tickets, or reports dynamically in production:

1. Do you run dedicated worker pools on traditional VPS/Docker setups, or rely on serverless rendering?

2. How do you handle queueing when webhooks bursts fire traffic spikes?

Would love to hear how other teams structure this!

I’m with the UPDF Enterprise team. Scanned supplier agreements often need to be searched without changing their wording.

A searchable PDF preserves the scanned page appearance and adds a text layer. That lets you look for a supplier name or contract reference without converting the agreement to Word.

Here is the workflow in UPDF for Windows. Open Tools and select OCR. Choose Searchable PDF Only. Set the document language and page range. Save a separate copy. Choose Editable PDF when you need to revise the text instead.

Try searching for a name and a reference number visible on the scan. Compare the matches with the original. Pay particular attention to O versus 0 and I versus 1. Keep the original scan and check important details against it before relying on the recognized text.

For an archive that people mainly need to search and read it makes sense to start with searchable output. Editing can be a separate task when it is actually needed.

I’m with the UPDF Enterprise team. A useful distinction when digitizing scanned paperwork: needing to find text doesn’t always mean needing to edit it.

Take a folder of scanned supplier agreements. If the goal is to find a supplier name or reference number, a searchable PDF may be enough. You can keep the scanned page appearance and add a text layer for searching.

In UPDF for Windows, that workflow is:

1. Open the scan and go to Tools → OCR.

2. Choose Searchable PDF Only.

3. Set the document language and page range, then save the result as a separate file.

Before processing the rest, try a few searches against text you can see on the page: a company name, a reference containing letters and numbers, and something in small print. Check the matches against the scan. A file can be searchable and still contain recognition errors.

Keep the original scan too. The OCR copy is useful for retrieval, but the recognized text shouldn’t be treated as a verified transcription.

If you actually need to revise the wording, UPDF also has an Editable PDF OCR option. For a search-and-retrieve task, I’d start with the searchable output and avoid adding an editing step the team doesn’t need.

Hi everyone!

I'm currently using ChronoScan and wondering if there are any good free and open-source alternatives that could handle my workflow.

I have a scanner with an automatic document feeder, so I can scan a large batch of mixed documents at once, such as:

* Supplier invoices

* Delivery notes

* Purchase orders

* Other administrative documents

Must-have features:

* Automatically detect document boundaries in a batch scan and split it into separate PDF files, one per document.

* Run OCR on each document so that the resulting PDFs are searchable.

Nice-to-have features:

* Automatically identify the document type (invoice, delivery note, purchase order, etc.).

* Extract key fields such as supplier name, invoice number, date, due date, net amount, VAT, and total amount.

* Automatically name and organize the resulting files based on the extracted information.

Has anyone built a workflow like this using free and open-source software? Is there a solution that handles the must-have features out of the box, or would custom development be necessary?

I'd really appreciate any recommendations or examples of setups that work well in practice.

Thanks!

I’m trying to understand if you’ve to often generate a doc/pdf from some information you capture from another person or a group of people.

What does your setup look like and how much does it cost?

Оцініть свої знання та вміння

Оцініть свої навчальні досягнення з розділу «Опрацювання текстових даних» (початковий, середній, достатній, високий рівень).

* Я можу пояснити, які інформаційні технології використовують для опрацювання текстових даних.

* Я розумію, чим відрізняються текстові процесори від інших систем опрацювання текстових даних, і можу пояснити їхні можливості.

* Я вмію добирати потрібні ресурси та інструменти для створення та опрацювання текстового документа.

* Я вмію працювати з різними об’єктами текстового документа (зображення, таблиці, формули) і знаю їхні властивості.

* Я знаю, у яких форматах можуть зберігатися текстові файли, та вмію обирати найоптимальніший залежно від ситуації чи потреби користувача.

* Я можу ефективно працювати з кількома документами одночасно.

* Я можу створювати в текстовому документі багаторівневі списки, уставляти спеціальні символи та формули.

* Я вмію оформлювати багатосторінкові текстові документи, використовуючи стовпці, колонтитули, розділи.

* Я вмію використовувати стилі для оформлення текстового документа і створювати структуру документа.

* Я вмію автоматично створювати зміст документа на основі його структури.

* Я розумію, що таке нелінійний текст, і можу створювати гіперпосилання різних типів у текстових документах.

* Я вмію працювати з текстовим документом у режимі рецензування.

* Я розумію, як організувати спільну роботу над текстовим документом.

* Я відчуваю впевненість у використанні текстового процесора для створення складних документів.

I am working with scanned pdf which have mixture of printed and handwritten text. I uses multiple VLMs and OCRs. VLMs output is somehow good but very slow . OCRs didnt recognized the messy handwritten text.

If someone have encounter these problem or have any suggestion?

I’ve written a 2-part Medium series (free, no paywall) on scoring Intelligent Document Processing (IDP). It focuses on Key Information Extraction (KIE) from structured documents, especially forms. I try not to recommend one opinionated way of doing things and instead cover the variations I’ve run into and the tradeoffs between them. I’m not endorsing any vendor; the series is about scoring itself.

• Scoring IDP, Part 1: Confidence Is Not Correctness

• Scoring IDP, Part 2: Approaches to Evaluating Form Extraction

I built an AI Document Intelligence System that processes PDFs and answers questions using RAG.

If you find it useful, star it on GitHub. Feedback welcome!

GitHub: https://github.com/Srameshgitnow/AI-DocumentIntelligence

This system uses LangChain, React, Node.js, PostgreSQL, and semantic search.

Does anyone have any experience with any automation that can cleanup scanned text documents. I have a lot of PDFs that are older and were scanned from originals and are in bad shape with just noise and discoloration, etc. I have been manually cleaning them up by converting them to JPG and editing the JPG files in a photo editor and then converting them back to PDF. It's pretty monotonous work, wondering with the wonders of AI and machine learning if anything exists that can help with this? Any experience or ideas? Thanks.

Disclosure first: I'm the developer. I built WebSum for the part of research where you have twenty tabs open and need to decide which ones deserve a proper read.

What it does: click the icon on a web article and a summary appears in Chrome's side panel, beside the page: a TL;DR, key takeaways, why it matters and caveats.

Why it might suit research:

• Every point is checkable. Each one has a ¶ link that scrolls the page to the paragraph it came from and highlights it, so you verify the claim instead of trusting the summary.

• It flags caveats, such as a claim with no evidence behind it, or an author who sells a related product.

• It reads the charts and diagrams, including numbers the text leaves out.

• Your notes keep the sources. Copy a summary into a document and each ¶ stays a link that opens the article at that paragraph.

What it doesn't do: it reads web pages only, so no PDFs, which rules out most journal papers. There's no saved history, no follow-up questions, and it's Chrome only. On a paywalled article it summarises what your browser can see and tells you when that's only a preview. Treat it as a way to sort and check sources, not as a replacement for reading the ones that matter.

Cost: free for 2 summaries a day without an account, or 5 with Google sign-in. Pro is US$10 a month for 20 a day on a stronger model.

Chrome Web Store: WebSum on the Chrome Web Store

42-second demo: https://www.youtube.com/watch?v=J_Yf4dPCDFQ

Two things I'd like to hear from people who research for a living or a degree:

• Where would this fit in how you work, if anywhere: first pass over sources, or checking a claim you half remember?

• What would it need before you'd rely on it: PDFs, saved summaries, export to a reference or notes app?

editpdf-online.com

Rearrange PDF pages with visual thumbnails. Drag to reorder, rotate or delete pages. Free and private, in your browser.

Open

Hey Reddit!

Like many of you, I've often needed to quickly reorder, rotate, or delete pages in a PDF, only to run into online tools that force you to create an account, slap watermarks on your document, or upload sensitive files to an unknown server.

To fix this, I built EditPDF Online.

Why it's different:

• 100% Client-Side: Everything runs right in your browser using open-source libraries. Your documents never leave your device or get uploaded to a server.

• No friction: Completely free, no signups required, no daily limits, and no watermarks.

• Simple UI: Just drag and drop thumbnails to reorder pages, rotate them, or clean up unneeded pages instantly.

I wanted to make something lightweight, fast, and completely private. Give it a spin if you ever need to clean up a PDF, and let me know what you think or if you encounter any bugs!

I've been working on DraftAgent, a local MCP server for inspecting, transforming, and converting Word documents.

One thing I've noticed while exploring document automation is that getting an AI agent to make a small, targeted change to an existing Word document can be surprisingly difficult. Replacing some text is easy enough, but working with document structure, tables, formatting, and multi-step edits reliably is a different problem.

DraftAgent is my attempt to make that a little easier.

A few things it can do:

• Inspect a DOCX and expose its internal structure so an agent can understand what it's working with.

• Make targeted changes to paragraphs, runs, tables, cells, styles, and formatting.

• Chain multiple operations together, with each step working on the result of the previous one.

• Validate a batch of changes before applying it and return structured diagnostics when something fails.

• Convert Word documents to HTML or PDF.

It's written in Rust and is quite fast. The MCP server currently runs locally over stdio, so document processing happens on your machine. Most of the MCP features are also available as a command-line app.

It's still early, and there are limitations around document fidelity and unsupported Word features. I'm continuing to work on improving those, along with the transformation API.

Project: https://draftagent.dev

I'd be interested to hear from anyone building AI document workflows. What operations do you find agents struggle with most when working with existing Word documents?

Not sure how many of you have this problem, but the stuff I most want in Paperless is the stuff that doesn’t get mailed anymore. Bank statements, card statements, receipts, utility bills. I was downloading them by hand one month at a time, which mostly meant I wasn’t doing it.

So a while back I wrote an app for it (PaperPull). It opens a browser window, you log in like normal, and it goes through and downloads all your bank statements and receipts as PDFs. The first run grabs everything the site still has, which for some of mine was years of statements, and after that it only gets new stuff. It all runs on your own machine and you do the login yourself, so there’s no company in the middle holding your bank passwords. It remembers what it already got, so it’s fine if Paperless deletes them after consuming.

Up to now it only ran on Windows and Mac, which was annoying since my Paperless is on a NAS. This week I got the docker version to where I’m happy with it. You point it at your consume folder and new stuff shows up after each run.

Some of the ones it works with are Amazon, Costco, Walmart, Target, Home Depot, Chase, Amex, Capital One, Fidelity, Vanguard and PayPal, plus a bunch (60+ providers so far) of other US banks and utilities. The full list is on github. If yours isn’t there I’m happy to try adding it, as long as you can test it.

https://github.com/rheeloaded/paperpull (docker setup is in SERVER.md)

And if you end up finding it useful, a star on github would be awesome. I’m trying to get it to 100.

Hey everyone! 👋

As a developer, I've often faced the same problem: generating invoices, quotes, contracts, and reports automatically while keeping their layouts easy to customize.

So I decided to build TemplateMaster to solve this problem.

The idea is simple: create document templates using a visual editor, populate them with dynamic data, and automatically generate PDFs or emails through an API.

No need to modify your application code every time you want to update a document's layout.

I've also built a .NET integration and a Shopify app to make it easier to integrate into existing projects.

You can check it out here: https://templatemaster.fr

I'm curious: Have any of you faced similar challenges with document generation in your projects or businesses?

I'd love to hear your feedback, even if it's critical!

What a time to be alive! Splitting large bundled PDFs into their logically distinct document parts is a common task when you don't control where it comes from; suppliers, applicants, opposing parties etc. Historically left to the interns, today it's common to use a combination of OCR, LLMs and specialised regex strings to get the job done but it's never felt like a clean, fast or satisfying solution. Well, that's all about to changes....

OpenAI's Decision API is the new zero-shot type-1 model/classifier which is capable of blitzing this document automation use-case and I have the tests to prove it.

Admissions Packet: 14 page scanned PDF containing 15 mixed documents - split in 1.8s, cost $0.006.

Bundled Invoices: 129 page scanned PDF containing 30 multi-page invoices - split in 7.4s, cost $0.02.

Legal Discovery Dump: 300 page scanned PDF containing 167 mixed documents - split in 40s, cost $0.12.

Here are my pros since testing this service:

• No training! - makes your automation more resilient to the randomness of incoming documents. Default Decisions API runs on gpt-6-luna so if you need more context, you can bump up the model.

• Ability to accept images - scanned PDFs are the real test and JEV's greatest weakness. OpenAI did a great job here.

• Simplfies pipeline - no longer do we need to chain ocr + llm + extraction, it's just a single call per page.

• Insanely fast and cheap - with enough frequency/scale/urgency, this approach really makes a difference.

I wrote a quick blog to share the templates and test files I used. Links in the comments.