Invoice line item extraction: why it is hard and how to get it right

Every invoice has a vendor, a number, a date and a total. Getting those right is mostly a solved problem. The line items (each row of description, quantity, unit price and amount) are different: no two vendors lay them out the same way, and a single misread digit can change what you pay.

When you need line items, and when you do not

Capture line items when you:

• match invoices to purchase orders or receipts line by line,
• code different lines to different GL accounts, departments, jobs or properties,
• track unit prices over time to catch price creep, or
• need freight, fees or tax broken out from the goods.

If you post one total per invoice to one account, skip them. Header-level capture is faster to review and you can always add line items later for the vendors where they matter.

Why line items are hard

What good extraction looks like

• One row per item, in the printed order

  The row count matches what you count on the page.

• The columns you need, mapped consistently

  Typically description, quantity, unit price and amount; often item or part number, unit of measure and PO line.

• Values shaped correctly

  Quantities and money are numbers, not text; negative lines stay negative.

• Non-item rows handled on purpose

  Freight and tax either captured as their own lines or kept out, the same way every time.

• Every row checked

  Arithmetic that fails is flagged, with the row and the reason.

• The table and header agree

  The lines add up to the subtotal or total printed at the bottom.

Math checks: a worked example

Arithmetic is the best friend of line-item extraction, because it lets software (and you) check a reading without looking at the page. Take the sample invoice from Northbridge Office Supply shown below:

There are two checks worth running on every invoice:

1. 01

   Row check: quantity × unit price = amount

   Allow a cent of rounding. A row that fails is either a misread or a vendor error, and both deserve a look.
2. 02

   Table check: the lines add up to the total

   Sum the amounts and compare with the subtotal, or with the total after tax, freight and discounts. This catches a missed or duplicated row, which a row check cannot.

Now suppose the first amount is misread as 141.00. The row check fails (4 × 35.00 is 140.00), and the lines would sum to 481.00 against a printed total of 480.00. Without a check, that extra dollar goes straight into your books.

Click to enlarge

Exception review that does not slow you down

Line items generate more exceptions than header fields simply because there are more values. Review has to be quick or the team will stop doing it properly. Look for:

• Only the problem rows highlighted, with the reason (does not add up, amount missing, low confidence), and a filter to show just those rows.
• The page and the table side by side, so you can compare a row without hunting.
• Row editing: add a missed row, delete an invented one, fix one cell.
• A way to teach the table, so the next invoice from the same vendor is read correctly.
• One keystroke to confirm the whole document once it is right.

In CapturePoint 6 the table under the page shows a count such as “1 to check” or “1 amount missing”, rows can be added and confirmed, Teach table teaches the layout, and Ctrl+Enter confirms the whole document. Each confirmation teaches the job, so the same vendor’s next invoice needs less attention.

How to handle multi-page tables

Long invoices (distributors, utilities, freight, anything with dozens of lines) are where tools differ most. Most of the work is making sure the pages arrive together and the table is read as one.

1. 01

   Keep the pages together

   Separation comes first. If page 2 is split off as its own document, no table logic can recover. Check multi-page invoices specifically in any pilot; separator sheets are a safe fallback for the vendors that cause trouble.
2. 02

   Expect repeated headers

   Many vendors print the column headers again at the top of each page. They must not become rows.
3. 03

   Drop carried-forward lines

   “Subtotal carried forward” and “brought forward” lines repeat amounts already counted. Including them double-counts.
4. 04

   Find the real totals

   Totals are usually on the last page, and some vendors also print page totals. Your table check should compare against the invoice total, not a page total.
5. 05

   Count the rows

   The quickest sanity check on a long table: the extracted row count against the last line number on the invoice.

Test this on your own longest invoices before you buy anything. Do it in the CapturePoint 6 free trial as well: compare the row count and the sum against the printed total, and you will know in minutes how it handles your vendors.

How to test a tool on line items

• Pick ten invoices with tables that worry you

  Wrapped descriptions, discounts, freight lines, credit memos, two or more pages.

• Write down the correct row count and total for each

• Run them and compare row counts first

  Missing or extra rows are the most expensive errors.

• Then compare amounts, and check that every bad row was flagged

• Correct one invoice per vendor, then run the next one

  Does the tool learn, or make the same mistake again?

• Time the review of a long invoice end to end

• Check what the exported data looks like

  One row per line, with the header values repeated or linked, in a format your accounting system can import.

Where to go next:

• Header fields, accuracy and local vs cloud: the invoice OCR buyer guide.
• Setting up the whole AP flow: the AP document capture checklist.
• CapturePoint setup articles: the CapturePoint help library.