Catch weight, pack quantity, price per pound — buried inside a single product description on a 150-line food invoice. Most tools read it as one blob. Harold learns to split it, row by row, so the mis-bills surface before they reach your ledger.
The problem
A dry-goods distributor knows every box of crackers weighs the same. A meat, cheese or seafood distributor deals with the opposite: every case weighs something different, and that difference decides what the customer owes.
That variable weight — the catch weight — is what a case actually weighed when it shipped, and it's what the supplier bills against. But on the invoice it's rarely a tidy column of its own. It's tucked into the product description, next to the pack count, next to the unit, in whatever shorthand that supplier happens to use. One line might read “Smoked Kielbasa (1lb-vp) By LBS”. The next, “Chicken Breast 2.5kg x 4 · Case”. Same column. Completely different data.
The error that never gets caught: invoiced at the 4/5LB pack price instead of the 6/5LB pack price. Pennies per case. Undetectable if all you capture is the invoice total — and impossible to spot by eye on line 118 of 152, at 7am, across five suppliers' deliveries.
A well-drilled buyer would catch some of it. But “read every description on every line of every invoice and mentally separate the pack count from the weight from the unit price” is not a job a human does reliably at volume. It's a job for something that reads the same field the same way, every row, every time.
What Harold does differently
You point Harold at the description field once and show it what to pull. From then on, every row gets split into the columns you actually need — catch weight, pack quantity, weight per case, price per pound — each landing in its own place, ready to check against what you were charged.
Notice the third row carries the weight in both kilograms and pounds, jammed together with a slash — the kind of shorthand that trips a rules engine written for one format. You don't write a rule for it. You highlight the number you want in a couple of example rows, and Harold works out the pattern.
The kind of invoice we mean
A single delivery, mixing case-pack ambient goods with by-the-kilo meat and cheese. Catch weights populated on some lines and blank on others. Pack counts and weights folded into the description. Multiply it by five suppliers a week.
Illustrative invoice. Fictional distributor and figures, built to show the three data types Harold separates: the catch-weight column, the pack quantity and weight inside each description.
How you train it — no rules, no regex
Multi-data training is the part food teams tell us they expected to be hard and weren't. You never write an extraction rule. You mark the number you want in a couple of example rows, and Harold generalizes it across the whole invoice — this month's and every month after.
Add the column you want — say weight per case — and switch it to multi-data. That tells Harold this value lives inside the Item Description text, not in a column of its own. It's one toggle.
Harold shows you actual lines from your uploaded invoice. You drag over the 11.88 in “5.4kg / 11.88lb”. Do it on two or three rows — including one where the value genuinely isn't present, so Harold learns when to leave the cell blank instead of guessing.
Before you commit, it tells you what it's going to look for — “a number that appears after a slash and immediately before lb”. If that's not what you meant, add another example and it refines. No pattern language to read or debug.
Save it against that supplier's profile and it applies automatically — on manual uploads and on invoices that arrive by email. The live preview fills the column in front of you so you can see it working before anything is exported.
Recreated training view · invented sample rows. The real panel looks and behaves the same in-app.
| Item description | Pack qty | Lbs / case | Catch wt | Price / lb |
|---|---|---|---|---|
| Chicken Breast Boneless 5lb x 4 | 4 | 20 | — | 2.10 |
| Hard Salami Whole 5.4kg / 11.88lb | — | 11.88 | 11.88 | 8.10 |
| Prime Beef Sirloin Whole · By LBS | — | — | 9.08 | 4.05 |
| Ground Beef 80/20 5lb x 6 | 6 | 30 | — | 3.29 |
| Cheddar Block Sharp · By LBS | — | — | 8.48 | 3.62 |
Every trained column fills row by row. Blank where the value genuinely isn't on that line — not a guess.
And when a value is ambiguous
No extractor is right 100% of the time on messy free text, and any tool that claims it is hasn't met your suppliers. What matters is what happens on the hard rows.
When a description is genuinely unusual — a weight written in a format Harold hasn't seen from that supplier, or a line total that doesn't reconcile against pack × weight × price — Harold marks it for review rather than pushing a wrong number into your export. You add one more highlighted example and it learns the new format for next time. The goal isn't a black box that's occasionally confidently wrong. It's a column you can trust because you can see, and correct, exactly how it was filled.
Keep reading
Invoices, POs and GRNs from suppliers on legacy ERP — the same multi-data approach, applied to production paperwork.
Why a tool built around your own rules handles catch weight and pack size where a fixed-field capture tool can't.
Push the separated columns straight into QuickBooks, Sage, NetSuite or your food-distribution ERP via Zapier — no re-keying.
The wider picture: train once per supplier, extract, validate and route every future invoice automatically.
Plain OCR reads the description as one string. Splitting it into reconcilable values is a different job.
Start on the Founder rate. Train your first supplier profile free and see a real export before you decide.
Upload a delivery you've already paid, highlight the numbers you wish were in their own columns, and see the export. Ten minutes, your data, no rules to write.
Start free