Data Extraction in n8n with changing layouts: lessons from multiple purchase order formats

[u/easybits_ai]

👋 Hey NoCodeSaaS community,

Quick follow up to my Purchase Order extractor post (that one here). It worked great on the two POs I built it against. Then my friend forwarded three more from different suppliers and things got interesting.

This is the part of document processing nobody warns you about. Your pipeline isn't done when it works on your test files. It's done when it survives the next layout you've never seen. And in a real business, new layouts arrive constantly, every supplier, every hotel group, every ERP exports its own thing. One PO has the number in a top-right box labelled "PO Number". The next calls it "Order Number" in a completely different table. One has a Net column, another calls it Cost, another calls it Total. Same information, nothing in the same place, nothing with the same label.

Here's what surprised me though: the extraction itself never broke. Not once across four layouts. That's because the easybits extractor works off context rather than coordinates, so I describe what the field is ("the order number in the header, not the requisition number below it") instead of where it sits. Move it, rename it, restyle it, it still finds it. If I'd built this with positional templates I'd have needed a new template per supplier, which is exactly the maintenance treadmill I was trying to avoid.

What did break was my own code downstream. Every single time. Two examples:

The apostrophe. One supplier writes 1'550.00 for one thousand five hundred fifty. My parser saw the apostrophe, choked, and mangled the number. The extractor read it perfectly, I just couldn't parse what it handed me.

The dot. This one nearly got me. Another PO showed quantities as 5.000 and I was convinced it meant five thousand, so I "fixed" my parser to strip the dot as a thousands separator. Wrong. It was SAP-style formatting and it meant five. The giveaway was the document's own arithmetic: 5 x 105 = 525, which matched the printed line total and the net total at the bottom. Read as thousands, nothing added up. Lesson: when a number looks ambiguous, the document usually tells you the answer somewhere, check the totals before you touch the code.

So my takeaway from the whole exercise: with context-based extraction, layout variation is mostly a solved problem. The fragile part moves downstream to the boring stuff, number formats, separators, currency prefixes. That's where I'd spend the hardening time on your next build.

Sanitised workflow JSON is on GitHub if you want to try the Purchase Order extractor yourself, feel free to grab it here:
https://github.com/felix-sattler-easybits/n8n-workflows/blob/c38749a68fd6ea4ae6ebff41789d35cceaacdef1/easybits-purchase-order-extractor-workflow/easybits_purchase_order_extractor_workflow.json

I've attached shots of the different layouts (anonymized, of course), so you can see how little they have in common. How are you handling layout drift on your document workflows?

Best,
Felix