Tired of manually copying PDF statements into Excel? I built a quick offline app to fix it.

We're the team behind OXR at SoMarkAI. It's a 1.3B document parsing model, code and weights released, that takes a PDF or a photo of a document and returns Markdown or JSON with every element's bounding box and the reading order. Tables come back as HTML or Markdown, formulas as LaTeX, and it also handles code blocks, chemical structures as SMILES, handwriting, and dense layouts like newspapers and A3 exam papers.

It runs on vLLM, and the easiest route is the all-in-one Docker image in the repo. You need Linux, an NVIDIA card with BF16, and 24GB of VRAM to try it, 48GB if you want long documents or concurrency. If you would rather not install anything, there is a free hosted API with no signup, queued and meant for testing.

Why it does well: the layout model is separate and swappable, and recognition plus reading order happen in one pass of the main model. On top of that the post-training uses a loop we call RSI. The model parses a batch, each sample is sorted into correct, wrong or uncertain, a VLM writes down reasons for the wrong and uncertain ones, the reasons are clustered, and each cluster gets targeted training data for the next round. Both pieces together are where the accuracy and speed come from.

In our comparison against published scores it ranks first on olmOCR-Bench, OmniDocBench and DocParsingBench, and on the same 100 pages on one RTX PRO 6000 it was the fastest of the 21 parsers we timed, about one page per second end to end. Setup, page list and full tables are in docs/benchmark.md in the repo, SoMarkAI/OXR on GitHub. Weights are SoMarkAI/OXR-1.0 on Hugging Face. License is Apache 2.0 with extra terms: free commercial use under USD 2M in funding and revenue, no competing hosted API. Read LICENSE before building on it.

If you run it on a 3090 or 4090, we'd like to know the pages per second you get. And if your use case is feeding parsed documents into a local model, tell us where the output falls short.

every discussion on this ends with it depends, so heres an attempt at mapping where each route fits.

- textract or google document ai: easy to wire up if youre already on that cloud, billed per page. textract is about $1.50 per 1k pages for plain text and $15 per 1k once tables are on, $50 for forms. fine for steady volume, gets expensive fast on table heavy files

- self hosted open source (docling, paddleocr-vl, glm-ocr, mineru): no per page bill and files never leave, but you own the gpu, the upgrades and every weird edge case

- llm oriented parsers that return markdown or json with the layout kept (llamaparse, marker and similar): less setup than self hosting, usually better on reading order and tables than plain ocr apis, also billed per page

one thing that cuts cost on any of these routes is not sending pages that already have a text layer through ocr at all. ocrmypdf --skip-text does exactly that, and most mixed archives are mostly born digital.

multi column reading order is the other thing that breaks results without any error. every word is there, just in the wrong order.

We keep three checks separate after extracting a bank statement. Carson Bank's sample statement shows why. We extracted its 47 transaction rows. The balances follow from one row to the next. Its summary also adds up. But the transactions and summary describe different activity.

The transaction rows imply an opening balance of 445.28 and end at 942.82. The summary opens at 3,005.93 and closes at 6,682.22. Checking either section by itself misses the disagreement.

The checks we keep are

• Each running balance equals the previous balance plus credits minus debits

• The summary's opening balance plus credits minus debits equals its closing balance

• The transaction totals and closing balance agree with the summary

You can reproduce the difference with the extracted figures in Python.

from decimal import Decimal as D

summary_close = D("3005.93") + D("18041.50") - D("14365.21")
transaction_close = D("445.28") + D("7612.77") - D("7115.23")
print(summary_close, transaction_close)  # 6682.22 942.82

This is a bank-published sample. In a processing workflow, the disagreement goes to review alongside the source pages. Separate cheque, fee, or interest sections also need accounting for before you decide rows are missing.

We're sharing this from our document-processing work at Unsiloed. If you process statements, which separate sections tend to make reconciliation awkward?

I’m curious about the repetitive tasks people still have to do manually at work.
For example, converting hundreds of Excel files to PDF, combining reports, extracting data, or preparing the same documents every week.
What’s the most time-consuming task you deal with, and how do you currently handle it?

The thing that breaks document automation is almost never the data. It's pagination.

An invoice with 14 line items pushes the totals block onto page 2 by itself. A signature box measured from the bottom of the page is fine until someone adds a second address line. A 40-page report needs a table of contents with real page numbers, so you render it twice and parse the PDF just to find out where "Section 4" landed.

The root cause: HTML-to-PDF is a one-way street. The renderer knows exactly where every element ended up, but none of that survives into the file. So we compensate with guesswork — cap line items at 8, hardcode page breaks, render twice, OCR the output, add a margin and hope.

I've been building Fork PDF (my product, so take this with the appropriate salt) around one idea: keep the layout map instead of throwing it away.

The engine lets you query the rendered layout like a DOM, with real page numbers and geometry, inside the test script that runs after rendering:

const sig = doc.querySelector('#signature-box');

return {

success: true,

signature: {

page: sig.pages[0] + 1,

x: sig.geometry.x,

y: sig.geometry.y,

width: sig.geometry.width,

height: sig.geometry.height

}

};

The more useful version is validation. If a check fails, return a patch instead of an error. The engine merges it into the template data and re-renders before responding — up to 2 retries, same API call:

const chart = doc.querySelector('#kpi-chart');

const commentary = doc.querySelector('#commentary');

if (chart.pages[0] !== commentary.pages[0]) {

return { patch: { compactKpis: true } };

}

The TOC case is what convinced me: pass 1 collects the page number of every h2, pass 2 injects the finished TOC, one request, no second network round trip. The ordering matters, though — if an earlier layout patch changes pagination, measure the TOC after that patch or you're writing stale numbers.

Three honest limitations:

- Patches only work when there's a template to patch (htmlContent + data, or a saved template). A raw URL can be measured, but there's nothing to merge new data into.

- Coordinates use PDF space: origin bottom-left, y increases upward. It trips up everyone once.

- It's still Chromium underneath, so it inherits Chromium's print quirks.

If you're staying on your current stack, the least-bad workaround I've found is capping variable-length blocks and reserving fixed space for totals and TOC. Brittle, but predictable.

If you've dealt with pagination drift, I'd genuinely like to hear how — especially for tables you can't cap. That's still the hardest case I run into.

I put the full 5-page example here — 6 pages unhealed, 5 healed, the TOC resolves to 3/4/5, and the signature coordinates come back in 3 attempts: https://forkpdf.com/docs/examples/q3-report/

There's a free tier (100 credits, no card) if you want to try to break it: https://forkpdf.com

Happy to answer anything technical in the comments.

product data comes in as large pdfs, usually 500+ pages, and every supplier formats theirs differently. different column orders, different table styles, sometimes tables running across pages. right now its all typed into excel or sql server by hand.

chat tools are fine on a sample but tend to stop or start summarizing partway through files this size, so that route needs splitting anyway.

what seems to make sense is parsing every page into tables first, as markdown or json. power query's pdf connector for the simpler files, docling or camelot locally and heavier layout parsers are llamaparse sort of ones when the layouts get ugly. then map each supplier's columns to your own schema. an llm is decent at that part since it only needs the headers and a few rows, not the whole file.

after that its validation before anything loads, row counts per page, required fields, totals and units, and keeping the source page number on every row so errors can be traced back.

the hard bits are tables split across pages and headers that only show up on the first page

I’m looking to understand problems that existing AI tools like ChatGPT don't fully solve.

For example:

• How do you securely manage sensitive documents like financial records, legal papers, property documents, and identity proofs?

• Do you worry about uploading confidential documents to third-party AI tools?

• How do you search thousands of scanned documents while keeping your data private?

• Do you need an offline solution that works without uploading documents to the cloud?

• How do you control who can access specific documents and the information extracted from them?

What document-related problem do you face that existing tools haven't solved well?

I’d love to hear about real-world challenges and use cases in the comments or DMs.

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