u/easybits_ai

👋 Hey n8n for Beginners Community,

Tax season is coming, and it is always the same story: a year of invoices and documents dumped in one folder, sorted by hand in a panic. Last week I shared an invoice workflow that has been logging all of mine automatically, and now I am using this one to push each document into the right folder on top of that. Document classification is the quiet fix for the sorting part, and a few things make or break it no matter which tool you use.

A few things I learned building these:

Your categories decide everything. Classification falls apart when the buckets overlap, so an invoice, a receipt, and a statement each need clear, distinct definitions or the model will confidently file things in the wrong place. Fewer, well defined categories beat a long fuzzy list every time.

A label without an action is just a sticker. The value is not knowing a document is an invoice, it is the document landing in the right folder automatically. Always pair the classification with where it goes next.

Trust the confident ones, review the rest. I attach a confidence score and let the sure documents file themselves, while anything shaky gets flagged to Slack for a two second human check. That one step is what makes hands off filing safe instead of risky.

Here is a free template that does exactly this, routing invoices into the right Google Drive folder with Slack catching the uncertain ones: https://n8n.io/workflows/14960-classify-invoices-and-route-them-to-google-drive-with-easybits-and-slack/

How do you handle document sorting? Curious whether people classify on the way in or still batch it all at the end.

Best,
Felix

👋 Hey n8n Community,

Community nodes are where a lot of the real magic in n8n happens, the ones that collapse a tangled setup into something you can actually maintain. I want to share the one that did that for me, and hear which ones did it for you.

My headache was document extraction. My first attempts were a Frankenstein chain: one node to pull text, another to parse it, a Code node to normalize the mess, then more logic to cross check the output and catch the fields that came back wrong. It sort of worked, but every new document format cracked it somewhere, and I spent more time patching than building.

The easybits Extractor node is what finally fixed it for me (full disclosure: I worked on it myself, since there was no simple and robust extraction node built especially for n8n). Extraction, structured output, and a confidence score came out of a single node, so all the normalizing and cross checking I had bolted on by hand was just gone. One node did the job that five were doing badly.

The takeaway is not really about one node though. It is that when a part of your workflow keeps growing extra nodes just to hold itself together, that is usually the signal to go looking for a community node built for exactly that job, instead of hardening the workaround.

So, which community node saved you from a monster setup? What was the before and after? And if you have built a node yourself, feel free to drop it here too, I would genuinely like to see what people are using.

Best,
Felix

P.S.: If you want to see how the community node looks in practice, almost all of the document flows I built are on my GitHub: https://github.com/felix-sattler-easybits/n8n-workflows

👋 Hey AIStartupAutomation Community,

Tax season always sneaks up on me, and every year it is the same scramble: digging through email for invoice PDFs, saving them by hand, typing them into a sheet, and hoping I did not log the same one twice. This time I built a workflow so future me does not have to.

I connected it to my billing@ address, so from now on every incoming invoice gets processed automatically and I never touch it manually again. And for invoices that land on other addresses, I just forward them to billing@ and they get picked up the same way.

When a new invoice arrives by email, it gets read, logged, and announced, with no manual steps.

What it does:

• Watches Gmail for unread emails with attachments and filters out junk files
• Classifies whether an attachment is an invoice AND extracts the fields in one step
• Deduplicates on the invoice number so re-sends and re-polls never create doubles
• Appends new invoices to Google Sheets and sends a Telegram alert for each one

Two things worth stealing:

1. Classify and extract in one call. No separate "is this an invoice?" LLM node plus an extraction node. The Extractor returns the document class alongside the fields, so it is one request and fewer failure points.
2. Dedupe on a stable key. A sheet lookup on the invoice number before the append is the part that actually saves you when tax season hits.

Workflow JSON is here: https://github.com/felix-sattler-easybits/n8n-workflows/tree/e8dd8e754b87c02462942e2ae89149550979b066/easybits-invoice-intake-and-logging-workflow

It sits alongside 25+ other free n8n workflows in my repo, including plenty of finance ones, so a star is appreciated if it helps.

How is everyone else prepping for tax season in n8n?

Best,
Felix

👋 Hey n8n for Beginners Community,

Tax season always sneaks up on me, and every year it is the same scramble: digging through email for invoice PDFs, saving them by hand, typing them into a sheet, and hoping I did not log the same one twice. This time I built a workflow so future me does not have to.

I connected it to my billing@ address, so from now on every incoming invoice gets processed automatically and I never touch it manually again. And for invoices that land on other addresses, I just forward them to billing@ and they get picked up the same way.

When a new invoice arrives by email, it gets read, logged, and announced, with no manual steps.

What it does:

• Watches Gmail for unread emails with attachments and filters out junk files
• Classifies whether an attachment is an invoice AND extracts the fields in one step
• Deduplicates on the invoice number so re-sends and re-polls never create doubles
• Appends new invoices to Google Sheets and sends a Telegram alert for each one

Two things worth stealing:

1. Classify and extract in one call. No separate "is this an invoice?" LLM node plus an extraction node. The Extractor returns the document class alongside the fields, so it is one request and fewer failure points.
2. Dedupe on a stable key. A sheet lookup on the invoice number before the append is the part that actually saves you when tax season hits.

Workflow JSON is here: https://github.com/felix-sattler-easybits/n8n-workflows/tree/e8dd8e754b87c02462942e2ae89149550979b066/easybits-invoice-intake-and-logging-workflow

It sits alongside 25+ other free n8n workflows in my repo, including plenty of finance ones, so a star is appreciated if it helps.

How is everyone else prepping for tax season in n8n?

Best,
Felix

👋 Hey n8nbusinessautomation Community,

Year end is when all the document chaos catches up with small businesses at once, the shoebox of receipts, the contracts nobody tracked, the folder that is just "scan_final_2.pdf" forty times over. These are the three document workflows that saved my clients the most time this past year, all built around simple extraction and a place to put the data, and they are worth setting up now to make January far less painful.

1. Auto log every invoice and receipt as it arrives.
Extract the key fields (date, vendor, amount, tax) from each invoice and append them straight to a single sheet, so instead of sorting a pile in January your accountant gets one clean list and you can actually see your spending as the year closes. To make it fully hands off, use a Gmail trigger as the entry point, and it will process invoices attached to incoming emails automatically, no manual upload needed.

2. A contract renewal and cancellation watchdog.
Most auto renewals sneak through at year end because nobody is watching the dates. Extract the renewal term and notice period from each contract, store them, and get a Slack or email nudge before a cancellation deadline passes. This one tends to pay for itself the first time it catches a subscription you meant to drop.

3. Sort incoming documents by type automatically.
Classify each document as invoice, contract, statement, or whatever buckets you care about, then file it in the right place without touching it. By the time you need something for the accountant or the tax filing, it is already where it should be.

None of these are big builds, and that is the point: one entry point, one extraction step, one place the data lands. If you want a head start, my ready to use templates are here, most of them document focused: https://n8n.io/creators/easybits/

There are also a few more on my GitHub that I never uploaded to n8n: https://github.com/felix-sattler-easybits/n8n-workflows

Pick the workflow that matches your biggest year end headache and set up just that one this week. Something that quietly logs your documents all year beats a heroic cleanup every January, and if you get stuck setting any of these up, feel free to drop a comment or reach out, happy to help.

I actually run the invoice logging one on my own documents too, so everything is already sorted and ready when tax time comes around instead of me digging for it. Curious what everyone else is scrambling to get in order before the books close.

Best,
Felix

👋 Hey AIStartupAutomation Community,

Year end is when all the document chaos catches up with small businesses at once, the shoebox of receipts, the contracts nobody tracked, the folder that is just "scan_final_2.pdf" forty times over. These are the three document workflows that saved my clients the most time this past year, all built around simple extraction and a place to put the data, and they are worth setting up now to make January far less painful.

1. Auto log every invoice and receipt as it arrives.
Extract the key fields (date, vendor, amount, tax) from each invoice and append them straight to a single sheet, so instead of sorting a pile in January your accountant gets one clean list and you can actually see your spending as the year closes. To make it fully hands off, use a Gmail trigger as the entry point, and it will process invoices attached to incoming emails automatically, no manual upload needed.

2. A contract renewal and cancellation watchdog.
Most auto renewals sneak through at year end because nobody is watching the dates. Extract the renewal term and notice period from each contract, store them, and get a Slack or email nudge before a cancellation deadline passes. This one tends to pay for itself the first time it catches a subscription you meant to drop.

3. Sort incoming documents by type automatically.
Classify each document as invoice, contract, statement, or whatever buckets you care about, then file it in the right place without touching it. By the time you need something for the accountant or the tax filing, it is already where it should be.

None of these are big builds, and that is the point: one entry point, one extraction step, one place the data lands. If you want a head start, my ready to use templates are here, most of them document focused: https://n8n.io/creators/easybits/

There are also a few more on my GitHub that I never uploaded to n8n: https://github.com/felix-sattler-easybits/n8n-workflows

Pick the workflow that matches your biggest year end headache and set up just that one this week. Something that quietly logs your documents all year beats a heroic cleanup every January, and if you get stuck setting any of these up, feel free to drop a comment or reach out, happy to help.

I actually run the invoice logging one on my own documents too, so everything is already sorted and ready when tax time comes around instead of me digging for it. Curious what everyone else is scrambling to get in order before the books close.

Best,
Felix

👋 Hey n8n Community,

Year end is when all the document chaos catches up with small businesses at once, the shoebox of receipts, the contracts nobody tracked, the folder that is just "scan_final_2.pdf" forty times over. These are the three document workflows that saved my clients the most time this past year, all built around simple extraction and a place to put the data, and they are worth setting up now to make January far less painful.

1. Auto log every invoice and receipt as it arrives.
Extract the key fields (date, vendor, amount, tax) from each invoice and append them straight to a single sheet, so instead of sorting a pile in January your accountant gets one clean list and you can actually see your spending as the year closes. To make it fully hands off, use a Gmail trigger as the entry point, and it will process invoices attached to incoming emails automatically, no manual upload needed.

2. A contract renewal and cancellation watchdog.
Most auto renewals sneak through at year end because nobody is watching the dates. Extract the renewal term and notice period from each contract, store them, and get a Slack or email nudge before a cancellation deadline passes. This one tends to pay for itself the first time it catches a subscription you meant to drop.

3. Sort incoming documents by type automatically.
Classify each document as invoice, contract, statement, or whatever buckets you care about, then file it in the right place without touching it. By the time you need something for the accountant or the tax filing, it is already where it should be.

None of these are big builds, and that is the point: one entry point, one extraction step, one place the data lands. If you want a head start, my ready to use templates are here, most of them document focused: https://n8n.io/creators/easybits/

There are also a few more on my GitHub that I never uploaded to n8n: https://github.com/felix-sattler-easybits/n8n-workflows

Pick the workflow that matches your biggest year end headache and set up just that one this week. Something that quietly logs your documents all year beats a heroic cleanup every January, and if you get stuck setting any of these up, feel free to drop a comment or reach out, happy to help.

I actually run the invoice logging one on my own documents too, so everything is already sorted and ready when tax time comes around instead of me digging for it. Curious what everyone else is scrambling to get in order before the books close.

Best,
Felix

👋 Hey n8n Community,

Most extraction accuracy problems I have chased down were not the model's fault, they were the field description's fault. The description is the actual prompt, and every gap you leave in it the model fills with a guess. Here is how I write them now after a lot of extraction builds.

1. Say exactly which value you want, and where it lives.
A field called "date" will happily return any date on the page, the due date, the delivery date, whatever it sees first. Spell it out instead: the invoice issue date printed next to the invoice number. That precision is what stops the model picking the wrong but plausible value.

2. State the output format, do not hope for it.
Leave it open and dates come back in five different shapes and amounts arrive with random symbols and separators. I put the format right in the description: dates as YYYY-MM-DD, amounts as a plain number with no currency symbol. It is far cheaper to constrain it here than to clean it up in three nodes afterwards.

3. Tell it what to do when the value is missing.
This is the big one. A vague field pressures the model to produce something even when the value is not there, which is exactly how you get a confident wrong answer. I always add a line like: if this is not on the document, return null. A blank field is a signal you can branch on, an invented one is a landmine you find weeks later.

4. Keep line item fields atomic, put the rules up top.
For sub-fields inside a table or list, short noun phrases of a word or two work best, long instructions there just confuse it. Save the detailed rules and edge cases for the top level fields where the model actually has room to reason.

For most of my extraction jobs I run the easybits Extractor. It actually started as an internal tool we built for our own client projects, and after running into how fiddly reliable data extraction in n8n can be, we figured others were hitting the same wall, so we opened it up for external users too.

What are you using for extraction these days, and what is the one field that always gives you trouble?

Best,
Felix

👋 Hey n8n community,

Short build retrospective, because the lesson generalizes to any agentic workflow that touches money or data you actually care about.

I watched an AI agent handle outgoing invoices end to end: draft, attach, send. The demo looked great. Then I hit the failure mode that actually matters with agents: they don't fail loudly. A deterministic node throws a red error and stops. An agent just keeps going, confidently, and sometimes what it's confidently doing is wrong. A gross total off by a few hundred euros. A transposed digit in the IBAN. It "worked" every single time.

My first instinct was to fix the prompt. That's the trap. You cannot prompt your way to guaranteed correctness on numbers. So instead of trying to make the agent smarter, I gave it a guardrail it has to pass through.

What that looks like:

1. The agent doesn't get to approve its own work. It calls a sub-workflow tool that extracts the invoice fields, pulls the matching row from the books (Google Sheets), and compares every field in plain JavaScript. Code judges, not the model.
2. The tool returns a hard verdict, APPROVED or REJECTED, with the exact mismatch attached. The agent can't rationalize its way past it, because the decision already happened in code before the agent ever sees it.
3. On a reject it blocks the send and emails me the invoice value next to the book value. The quiet failure becomes a loud one, which was the entire goal.

The rule I keep coming back to: let the agent act, let deterministic code decide anything you can't afford to get wrong.

You'll find the workflow here: https://github.com/felix-sattler-easybits/n8n-workflows/blob/d6e4b7ca373fa1db40a55ef5b879210b601e8cba/easybits-agent-invoice-guardrail/easybits_agent_invoice_guardrail.json

Curious how the rest of you are putting guardrails around agents that take real-world actions. What's your pattern?

Best,
Felix

👋 Hey n8n Community,

A friend of mine, Jonas, runs a small B2B agency and recently let an AI agent handle his client invoices end to end: draft, attach, send. Felt great until a client emailed back confused about being billed a few hundred euros over the agreed amount. Same week, another invoice went out with a transposed digit in the IBAN. The agent was confident every time. The agent was also wrong.

That's the real problem with pointing an LLM at money. Ask it to "verify" an invoice and it will happily hand you an approval that sounds right and isn't. So I built a guardrail the agent has to pass through before anything gets sent. No vibes, just code checking numbers against your accounting records.

How it's set up:

• Trigger: the workflow runs as a sub-workflow tool the agent calls, receiving the invoice file URL and the invoice number.
• Download: pulls the invoice PDF straight from Google Drive.
• Extract: the easybits Extractor node reads 8 fields off the PDF (invoice number, customer, IBAN, VAT ID, net total, VAT amount, gross total, service period).
• Ground truth: a Google Sheets lookup fetches the expected values for that invoice number from your books.
• Compare: a Merge combines both sides, then a Code node checks every field deterministically (normalized currency, normalized IBAN, strict numeric tolerance).
• Decide: all match, it returns APPROVED so the agent can send. Anything missing or off, it blocks dispatch, sends an email showing invoice value vs book value side by side, and returns REJECTED.

Net effect: no overpayments, no invalid VAT math, no wrong-client billing slipping past an over-eager agent.

A few things worth knowing if you build something similar:

1. Never let the LLM grade its own numbers. Split the jobs: the model extracts or writes, code validates. A Code node with plain JavaScript gives you zero hallucinated approvals, which is exactly what you want anywhere near finance.
2. Normalize currency both directions before you compare. German 1.234,56 and English 1,234.56 are the same number written two ways. Strip the symbols, unify the decimal separator, parse to float, then compare with a small tolerance (I use 0.01) so rounding never triggers a false reject.
3. Watch the "null" string trap. The Extractor I'm using returns the literal string "null" for a missing field, not a real null, so a naive check passes it straight through. Write one isMissing() helper that catches real null, undefined, empty string, whitespace, and the string "null", and run every field through it.

Grab the workflow here: https://github.com/felix-sattler-easybits/n8n-workflows/blob/d6e4b7ca373fa1db40a55ef5b879210b601e8cba/easybits-agent-invoice-guardrail/easybits_agent_invoice_guardrail.json

Curious what guardrails you've put in front of your finance automations, especially anyone letting agents touch payments.

Best,
Felix

👋 Hey n8n Community,

A workflow that runs green once has not been tested, it has been demoed. Most of the trouble I have ever caused myself came from trusting a clean first run, so here is the routine I go through now before anything touches real client data.

1. Build the test set from the ugliest real samples I can find.
Clean PDFs prove nothing, so I go looking for the phone photos, the crooked scans, the stamped and two-language documents on purpose. If the workflow survives the worst inputs, the normal ones take care of themselves.

2. Generate the variety I do not have.
When I only have one or two real layouts, I ask an LLM to produce a few alternative versions with the same data points arranged differently, and I also make versions that are deliberately missing some of the data points so I can see how the flow handles gaps. It is a quick way to stress test against formats I have not seen yet instead of waiting for a client to surprise me. I actually showed how I build these example documents in my stress test video: https://youtu.be/bOOdILPEdho

3. Break it on purpose.
I deliberately feed it the wrong things: an empty file, the wrong document type, a field that is genuinely missing. The point is to confirm it routes those to review or fails loudly, rather than quietly passing a made up value down the line.

4. Run a batch, not a single document.
One good run tells you almost nothing, so I push through twenty or thirty at once and watch for drift. That is where the one weird edge case shows up, and it is far better it shows up on my screen than on the client's.

5. Check the output against the source, not just that it ran.
Green means it finished, not that it is right. I open a handful of results next to the original document and verify the fields that actually matter, the totals, the IDs, the dates, because those are the ones that cost real money when they are wrong.

Extra tip for big flows.
For larger workflows I explain the flow to Claude and hand over a flow chart, then ask it to build me a testing overview as a PDF. It often comes up with edge cases I would never have thought of, some of them wonderfully obscure, and I end up with a clean checklist I can work through case by case, ticking each one off and leaving comments as I go.

If you want to see how this shapes the builds themselves, I keep 25+ free workflow templates in one repo, most of them around document processing, and a star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

How do you test before going live? Curious whether people build a proper test set or mostly run it a few times and hope for the best.

Best,
Felix

👋 Hey n8n Community,

Quick update: my payment reconciliation workflow is now live and free in the n8n template library, and I recorded a short walkthrough running a full test so you can see the report before importing anything.

How it's set up:

• The form takes two .xlsx uploads: a bank statement on one side, your open invoices on the other
• Extract from File reads both, a Merge node brings them together
• A Code node cross-references every bank credit against the invoices
• The report renders right on the form completion screen: exact matches, partial payments, unpaid invoices, and unmatched deposits
• You can download that report as a PDF from the same screen for your finance team

A few things worth taking away even if you skip the video:

No credentials, so it runs the second you import it. It is only a form trigger, extract from file, merge, and code. Nothing to authenticate, which is what makes it easy to hand to someone else with zero setup.

Match loosely, but in a bounded way. Bank references are never clean. It matches on the full invoice ID when present, then falls back to the last three digits pulled from the reference with a small regex. That one fallback catches most of the "INV-2024-201" versus "ref 201 payment" cases.

The PDF is just HTML with a print button. The results page is styled HTML on the completion screen that calls window.print() for the download. No PDF node, no external service, and the report stays self-contained.

Template (import it straight into your instance): https://n8n.io/workflows/19010-reconcile-invoice-payments-from-bank-statements-using-n8n-forms/

Two example files, one bank statement and one invoice export, are sitting in the repo here, so you can test the workflow in a minute without building your own data: https://github.com/felix-sattler-easybits/n8n-workflows/tree/8e07427ddb6902ef8a7b267e97beb2879d6ca45d/easybits-reconciliation-workflow

Reconciliation tends to be specific to each company, so if you adapt it and get stuck, drop a comment and I will help. How does everyone else handle the messy reference matching?

Best,
Felix

👋 Hey n8n Community,

The scariest workflow is not the one that throws an error, it is the one that finishes green while quietly passing wrong data downstream, and nobody notices for weeks. Most of my error handling is just about turning those silent failures loud. Here is the setup I put on almost every build.

Know the difference between loud and quiet failures.
A node that crashes is the easy case, you see it straight away in the executions list. The dangerous one is the workflow that completes fine while handing a wrong or empty value to the next step, and everything below is about catching that second kind.

1. Turn "not sure" into a branch, not a guess.
When an extraction step cannot read a field it should return empty, not a made up value. I drop an IF right after it, and anything empty or low confidence gets pulled out of the main flow and sent to review instead of quietly moving on.

2. Alert yourself, do not just log.
Off those check gates I wire an error route that pings me on Slack the moment something looks off, especially during a client's first few weeks. That way I usually see the problem and fix it before the client even notices.

3. Log failures somewhere you can actually review.
Every caught failure gets appended to a Google Sheet with the input and the reason it failed. After a week you can see the pattern, and the fix is normally one bad assumption rather than a hundred random errors.

4. Wire up n8n's Error Workflow once.
For the hard crashes, an API being down or a node blowing up, n8n has a built-in Error Trigger. Build one small workflow that catches those and messages you, set it as your error workflow, and every workflow on the instance is covered with no extra work per build.

If you want to see this in real builds, I keep 25+ free workflow templates in one repo, most of them around document processing, and a star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

How do you catch silent failures in your workflows? Curious whether people mostly lean on n8n's Error Workflow, their own check gates, or something else.

Best,
Felix

👋 Hey n8n Community,

After building a lot of workflows over the last year, I noticed the same five nodes show up in almost every single one. None of them are flashy, they are just the nodes that quietly do most of the work in a build. Here they are, with a real example and one gotcha each.

1. Form Trigger.
Half my workflows start with someone uploading a file, and the Form Trigger gives them a clean hosted page to do it with zero frontend work on my side. My document classification flow takes a PDF or image through a form and hands back a result, and my reconciliation build takes two spreadsheet uploads the same way. Gotcha: uploaded files arrive as binary on the item, not as JSON text, so the next node has to read the binary property rather than a field value.

2. IF and Switch.
Routing is the backbone of keeping a workflow deterministic. In my document classification build an IF checks the confidence score, low confidence goes to Slack for review and everything else passes through, and a Switch sorts contracts into the right sheet by type. Reach for these before you reach for an agent, branching you can see beats logic hidden in a prompt.

3. Edit Fields (Set).
This is where I shape data: rename fields, set defaults, derive new values. In my contract renewal workflow I calculate the end date and cancellation deadline right here with date expressions instead of asking the model to extract them. Gotcha: do not put a leading = before a {{ }} in the value field, it quietly turns your output into [object Object].

4. Google Sheets.
The storage layer under most of my builds, the lightweight database you do not have to set up. My contract watchdog appends every contract to a five-tab sheet and the daily check reads all five tabs back to work out what is due, and my signup flow looks up the sheet first so the same person never gets added twice. Gotcha: everything comes back as a string, so a number or date read from a sheet needs converting before you calculate or compare on it.

5. Loop Over Items (Split in Batches).
Process items one at a time when a node cannot handle a whole batch cleanly. Whenever an extraction step sits inside the loop I set the batch size to 1, otherwise it processes all the input in one call and you get a single merged result instead of one per document. This is the fix for "why did my 10 invoices come back as one".

For the extraction step itself I use the easybits Extractor, a verified n8n community node that turns PDFs and images into structured data.

If you want to see these in real builds, I keep 25+ free workflow templates in one repo, most of them around document processing, and a star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

What are you mostly automating these days, and which nodes do you lean on most to get it done?

Best,
Felix

👋 Hey n8n Community,

The question I get most about extraction workflows is not "how do I extract the data". It is "what happens when it goes wrong?" Because it will. A blurry photo, a bad scan, a PDF in a wrong layout.

I set this up for Mike, who runs a small distribution business. His extraction ran fine for weeks, then a supplier tweaked their invoice template and it quietly returned nothing. No error, no alert. A blank invoice number went into the sheet, and it took one weeks to notice a payment had slipped. That is the trap with document automation: it fails silently, and by then the bad data has already spread.

So this is the safety net I now put around every extraction workflow.

How it's set up:

1. Gmail Trigger grabs the attachment as binary.
2. easybits Extractor pulls the data. When it cannot confidently read a field, it returns null instead of guessing.
3. IF node (is empty) checks the invoice number. That one operator catches nulls, undefined, and empty strings in a single condition.
4. On failure a Slack alert goes to finance with sender, subject, and timestamp for manual handling.
5. On success the file is merged back with its data and archived to Drive.

Two things worth knowing:

Null is a feature, not a bug. A model that returns null when unsure is far safer than one that hallucinates a plausible invoice number. Treat that null as a clean signal to branch on.

Confidence scoring is a thirty-second add. If pass/fail feels too blunt, add a confidence_score field to your mapping and route on bands: high goes through, mid gets a human glance, low hits the error branch. Same trick works for routing ambiguous docs in a classification flow.

Workflow is on the n8n library here: https://n8n.io/workflows/15098-catch-failed-invoice-extractions-with-easybits-slack-and-google-drive/

How do you handle extraction failures? Hard-fail and alert, or route low-confidence docs to a human queue and keep the pipeline moving?

Best,
Felix

👋 Hey n8n Community,

A while back I shared a purchase order extractor I built for a friend with a big online store who was working through PO PDFs by hand. It's now published on the n8n template library, so you can grab it for free.

What it does: you upload one or many PO PDFs through a form, and it extracts each into a Google Sheet, one row per line item, with the source document name on every row. It handles POs in different layouts, runs them as a batch, and before writing it checks each PO number against the sheet so nothing gets entered twice. The completion screen then tells you what was added, what it skipped as already processed (with the PO number), and whether any extraction looked off.

One thing worth pulling out if you build batch extraction of your own: a batch is only worth running if you can trust it without eyeballing every row. The feature that actually made this usable wasn't extraction accuracy, it was the summary that surfaces skipped duplicates and failed fields, so you know exactly what to check instead of assuming it all worked.

Template (free to grab): https://n8n.io/workflows/18674-extract-purchase-orders-from-pdfs-with-easybits-google-sheets-and-google-drive/

The optional EDI 850 add-on (for pushing orders into SAP and other ERPs) isn't in the library version, but it sits in my repo alongside 25+ other workflows: https://github.com/felix-sattler-easybits/n8n-workflows

If you're automating PO or invoice intake too, how are you handling the fact that every supplier sends a different layout? That was the hardest part to make reliable here, and I'd be curious how others approach it.

Best,
Felix

👋 Hey n8n Community,

Over the last year I have built document extraction into a bunch of client workflows. The models keep getting better, but the same handful of mistakes cause most of the pain, and almost none of them are about the model itself. Here are the five I run into most.

1. Building only the happy path.
Everyone tests on a clean PDF and ships, then production hands you a phone photo, a stamped scan, a two-language invoice. Test on your ugliest real samples first, because that is what the workflow actually gets fed.

2. Building for one layout.
It works on your one vendor's invoice, then a new supplier's template quietly breaks it. Test across as many real layouts as you can, and key off what a field means rather than where it sits on the page. If you do not have different layouts in your test data, I just ask my favourite LLM to generate a few alternative layouts with the same data points on them. It is a quick way to stress test against formats you have not seen yet.

3. Losing table structure.
Pull a table as one flat blob and rows drift, so quantities line up with the wrong description. This one I struggled with for a long time until I found the right way to do it: extract line items as structured rows with named columns, not free text. I made a short video walking through table extraction if it helps: https://youtu.be/qj4-zz9a13o

4. Ignoring what a 1% error rate means at volume.
99% sounds perfect until 1,000 docs a day is 10 silent errors daily, nothing crashes, the numbers are just wrong. Decide which fields must be right and put a check or review gate on those specifically. I usually wire an error route off those gates that pings me on Slack the moment something looks off, especially during onboarding, so I can react before the client even has to call.

5. Reaching for an agent when a rule would do.
People wrap an LLM around plain logic like date math or ID matching, and it breaks quietly instead of loudly. If you can sketch it on paper with the edge cases, make it deterministic and save the model for the fuzzy part. It is not just about robustness either, an agent can burn a lot of tokens on a task a simple rule would handle for free.

If you want to see what I have been building, I keep 25+ free workflow templates in one repo, most of them around document processing, and a star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

Happy to hear what everyone else struggles with most. Is it the messy inputs, the layouts that keep shifting, or something I have not run into yet?

Best,
Felix

👋 Hey n8n Community,

A few days ago I shared a reconciliation workflow that matches bank deposits to open invoices. A few people asked about the tricky parts, so here are the five things I took away from building it. Most of them are less about n8n and more about how messy real financial data is.

1. The reference field is where reconciliation dies.
Bank references almost never match your invoice IDs cleanly. You get "INV-2024-201", "ref 201", "payment 0201 thanks", all for the same invoice. So do not match on the exact string. Match on the full invoice ID when it is there, then fall back to a looser signal like the last three digits pulled out with a small regex. Fuzzy but bounded beats exact every time.

2. "Matched vs unmatched" is too coarse.
The moment I split results into four states instead of two, the report got genuinely useful: exact matches, partial payments, unpaid invoices, and deposits with no invoice at all. The two middle buckets are where the money actually leaks, and a simple matched/unmatched view hides them completely.

3. A deposit with no invoice is a signal, not noise.
Money landing in the bank that matches nothing is exactly what manual reviewers skip because they are focused on ticking off invoices. But that column is where the interest payments, refunds, bank fees, and typo'd customer references all show up. Give it its own table so nothing silently disappears.

4. Let the code do the arithmetic, keep the human for judgment.
The old manual process was someone staring at two spreadsheets for hours, which is exactly how 525.52 becomes 252.25. A Code node compares amounts to the cent and never gets tired. The person only reviews the handful of flagged exceptions, not the 90 percent that reconcile cleanly.

5. Every result needs a way back to the source.
Reconciliation you cannot audit is just guessing. So each row in the report keeps the original bank reference, the value date, and the invoice ID side by side. When a number looks off, you can trace it back in seconds instead of reopening the raw statement.

The workflow itself, plus two example files (an invoice export and a bank statement) so you can run it right away, is here: https://github.com/felix-sattler-easybits/n8n-workflows/tree/8e07427ddb6902ef8a7b267e97beb2879d6ca45d/easybits-reconciliation-workflow

It sits alongside 25+ other free n8n workflows in my repo, including plenty of finance ones. A star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

What is your reconciliation matching logic? I am especially curious how people handle one payment covering several invoices, because that was the case I found hardest to generalise.

Best,
Felix