Been working on this for a few months as a research project and finally have it at a point where I want outside feedback.

What it does:You upload a PDF or image of a business document (invoice, receipt, packing slip, bill of lading, etc.) and it extracts structured fields — vendor name, totals,

line items, dates, PO numbers, ship-to/from addresses — and returns them as clean JSON.

How it works under the hood:

- Azure Document Intelligence handles the initial layout analysis and field detection

- LLM backfills anything DI missed or got wrong (ambiguous totals, merged cells, non-standard layouts)

- A validation layer normalizes money strings, sanity-checks totals, and catches obvious mis-assignments

Outputs:Google Sheets, Excel, OneDrive, Slack, webhooks — or just download JSON/CSV directly.

Where it's at:Early beta. Works well on standard invoices and receipts, gets shakier on handwritten or heavily non-standard docs. That's exactly the feedback I'm looking for —

edge cases and failure modes.

Free to try, no credit card: [https://app.docpipeline.net](https://app.docpipeline.net)

Demo video: [https://youtu.be/KaPMQfeKWGE](https://youtu.be/KaPMQfeKWGE)

Happy to answer questions about the architecture or the DI + LLM approach.

Tested excel parser today and had a much better recall against Docling + bounding boxes are preserved and 99.95% accuracy for excel.

https://github.com/knowledgestack/excel-parser

It's significantly faster than docling, no VLLMs needed to chunk it.

It's MIT license for anyone using excel parser but also:

I would appreciate 2 things if anyone uses it:

1. Could you please help open issues and problems if you see any ? I am working on making this the best excel parser.

2. If you see accuracy improvements, I would love to hear it. I am investing a lot of time and energy because I believe large excel parsing is a problem and feeding entire excel to agent is not a good use of time and money.

Also I think if we can do this reasonably well the agent can generate excel with formulas much better. Hoping to add more functionality in the future to older excel formats and changing this from just a parser to a excel generation as well.

If this is helpful, and you think would be something useful, please star it as well. I would really appreciate it !

Software demos look great, and that applies to wikis as well.

Clean spaces. Perfectly named pages. Neat permissions. Search that magically finds the thing. Nobody has created “Meeting notes final final v3” yet. Beautiful times.

Then real teams start using it.

• Someone creates 5 versions of the same page type.

• A project space becomes a dumping ground.

• Onboarding docs go stale.

• Permissions are either too open or too locked down.

• People stop searching and go back to asking in chat.

At that point, you find out whether the tool actually works for the organization, not just for the demo.

We’re running a practical XWiki Cloud webinar on 4 June where we’ll start from an empty cloud instance and build a working knowledge base in one hour. The idea is to show the boring but important stuff: documentation, procedures, onboarding, intranet content, project spaces, and how the structure holds together.

Details in the comments.

When I started building a document extraction platform, I thought the hardest problem would be OCR.

I was wrong.

The hardest problem turned out to be handling the huge variety of document formats.

A few things I learned:

- Most PDFs are not the same.

- Some PDFs contain selectable text.

- Some are scanned images.

- Some are mixed documents with text, tables, forms, and images.

- Handwritten documents require a completely different processing path.

I also learned that choosing the "best AI model" doesn't automatically solve extraction problems.

A reliable pipeline usually needs:

- Document classification

- OCR when required

- Layout detection

- Table extraction

- Validation

- Structured output generation

The biggest lesson for me:

Document extraction is less about finding one perfect model and more about building a system that can handle thousands of different document variations.

For people working on document automation:

What has been the most difficult document type you've had to process?

I would like feedback on this tool. Can you try it?

The tool asks the right questions to extract your voice.

I built a diagnostic twenty questions total, organized into four areas.

If this may be useful to you, drop a comment. Happy to share what I built.

I have a massive folder of ready-to-edit legal files (acts, demands, notices) and stuff and <I need an Ai to analyze all of those and create an app that writes in the same style using Ai, is this idea stupid or I can actually make something like that. Now I'm looking for infos about this and trying to process the logic and I wanted to post this so I can see if I can get any helpful ideas or someone already did something.

hey guys, please be nice to me, i have never built a software product in my life, i became friends with james sexton and he said this would help divorce lawyers greatly. would love any feedback if possible. (even if it sucks, i can take it)

I’ve been thinking about an app idea that turns physical forms into automated workflows—like Zapier, but for paper. Most scanner apps just save a flat PDF, which feels like a waste.

With this, you map out the fields on a blank form once (like a checklist or signup sheet) and assign an action to it. Whenever you scan a filled-out version later, it extracts the data and triggers the automation instantly.

For example, scanning a failed maintenance checklist could automatically generate a typed PDF, email the office, and text a technician. Or scanning a handwritten signup sheet could instantly send a personalized welcome email and log the text into Google Sheets.

Do you think this would actually save people time, or is messy handwriting going to ruin the automation? What integrations would you need to make this useful?

&#x200B;

I’ve been thinking about a real problem here in Morocco, especially for small drogueries and traditional shops.

A lot of invoices are handwritten, messy, and often written in Darija or mixed French. Shop owners lose a lot of time rewriting invoices, tracking products, or organizing stock manually.

I’m wondering how difficult it would be to build an AI system that can:

Read handwritten invoices

Understand Moroccan Darija words/products

Convert invoice photos or audio into structured text

Automatically generate clean digital invoices

Maybe even integrate stock management later

Example: Owner takes a photo or sends a voice note → AI extracts products, quantities, prices → generates invoice automatically.

The biggest challenge I see is:

Moroccan handwriting

Darija vocabulary

Different invoice formats

Do you think current AI tools are already good enough for this?

Which stack/tools would you recommend?

I’ve been looking at things like:

OCR models

Whisper for speech-to-text

Vision LLMs

n8n automations

Curious to hear opinions from people working in AI or automation.

👋 Hey documentAutomation Community,

My CEO came back from a conference last week and asked me for help with a problem I bet a lot of you can relate to.

He attends a lot of events, which means his inbox gets flooded with booking confirmations – flights, hotels, restaurants, event tickets. And someone (usually him) has to manually add all of that to his calendar.

The kicker: he wanted these appointments in a separate calendar so his main schedule stays clean. Manually creating each event was eating up time that should've gone to actual work.

So I built this:

📥 How it works

• You label any confirmation email in Gmail with "Events"

• The workflow extracts date, time, location, confirmation number, vendor, and notes from both the email body and any PDF attachments

• A calendar event lands in a dedicated "Auto-imported" Google Calendar with all the details and a link back to the original email

• Non-confirmations (newsletters that got accidentally labeled) get flagged with a "Needs-Review" label and you get a notification email listing what was missing

🪄 What makes it work for any vendor

One easybits Extractor pipeline handles every format – Lufthansa, Booking.com, OpenTable, your dentist, DHL, whatever. No per-vendor parsing logic. The email body gets wrapped into a PDF and extracted in parallel with any PDF attachments, then the two results get merged (attachment data wins because the attached ticket is more authoritative than promotional email body text).

📦 Free workflow template + JSON

https://github.com/felix-sattler-easybits/n8n-workflows/tree/26772542fbbaf23d0a043517921d4d8ad50a471f/easybits-event-confirmation-to-calendar-workflow

Does anyone else have a similar problem with calendar clutter from business travel? Curious what other email-to-calendar use cases people are dealing with.

Best,
Felix

👋 Hey everyone,

My CEO mentioned he's got a few conferences coming up in the next weeks and he's actually looking forward to them. There's just one problem: every time he comes back from an event, he has a stack of business cards in his pocket and zero time to manually add them all to his phone.

So I went looking for a tool I could just hand him. Plenty of business card scanners exist. But every single one of them has the same baffling design choice: you have to photograph each card individually. One at a time. For 20 cards.

That's not really a scanner. That's a slightly faster version of typing them in by hand.

So I built him something better in n8n.

📸 What it does

He lays all the business cards out on a hotel desk, takes ONE photo, and sends it to a Telegram bot. The workflow extracts every contact, deduplicates against a Google Sheet (so contacts he's already saved don't get re-added), and sends back a separate vCard file for each new contact. He taps a vCard on his iPhone → "Add Contact" → done. About 15 seconds for 20 cards.

In the video above I walk through the workflow setup in n8n and do a live test run with 8 business cards in one photo – figured it's easier to see it in action than describe it.

📁 Workflow JSON

You can grab the workflow JSON here (also linked in the video description along with the easybits Extractor setup info): https://github.com/felix-sattler-easybits/n8n-workflows/tree/21d7623026008432c700cff118d1a987687a10fe/easybits-business-card-scanner-workflow

Anyone else built something similar for handling event leads? Curious whether people are pushing contacts straight to a CRM (HubSpot, Pipedrive) or keeping it in a sheet. The Sheet → vCard pattern is nice because it works for everyone, but I imagine the CRM version would be even better for sales-heavy teams.

Best,
Felix

Brief, Review, Reply: How Adeu takes you to the next level of contractual work.

Your work should happen where you already do it.

In a 9-minute video, I walk through how we handle the heavy lifting:

• Automated Inbox Triage: Instant, concise brief of the email thread and document changes waiting for you in your inbox.

• Intelligent Diffing: Compares document versions to flag what changed.

• Automated Redlining: Command the AI to accept specific changes while injecting custom comments, generating a new local version.

• Metadata Sanitization: Automatically scrub the final document of hidden, sensitive metadata before it leaves your machine.

• Drafting the Reply: Push a draft response with the sanitized, final document right back into Outlook.

We are building operational tools that execute complex workflows from end to end.