Documents and AI
Documents with tables
A single field almost always reads fine. A table fails elsewhere: not on the number, but on the row.
A certificate has a number, a date and a holder: three loose fields, and they read fine. An invoice, a delivery note or a results listing have twenty rows of four columns, and there automatic reading behaves differently — not worse in the way you would expect.
Where it actually fails
| What people fear | What actually happens |
|---|---|
| That it misreads the number | The number usually reads fine: the digits are large and clean |
| That it skips a row | It happens, and it is visible: the total does not add up |
| — | What really fails is which row each value belongs to |
| — | And rows continuing onto the next page, which get split |
Important
That third point cannot be spotted by looking at the result: **a correctly read value can end up in the wrong row**, and then everything checks out separately while the whole thing lies. The sum works, every number exists in the document, and yet one reference's quantity has landed on the next one. When the breakdown matters and not just the total, check two or three random rows, not the total.
What makes a table read well
Watch out
If you define the table and a supplier fills it in, there is a far better way out than tuning the reading: **ask for the same data in a form rather than inside a document**. A scanned delivery note has to be read; a form with one line per reference does not. It takes the same time to fill in and the whole problem disappears.
How to check it without rereading the whole document
- 1
Check the total against the sum of the rows
Catches the missing row and the duplicated one.
- 2
Pick two rows at random and compare the whole row
Not the number: the entire row, to see whether it is aligned.
- 3
Look at the page break
That is where a row splits, and where nobody looks.
- 4
And correct in the platform, not on the document
That way there is a record of what changed and who changed it.
Worth knowing
If a document with tables reads badly time after time, it is usually the document rather than the reading: same supplier, same template, same failure. Raising it with whoever issues it fixes all the following ones at once.
›Should I extract every line?
Only if you will use them. If the total is enough, asking for less fails less.
›What about a spreadsheet?
Far better: there the rows are real rows, not a picture of rows.
›Does uploading at higher resolution help?
It helps read the digits, not place the rows. Different problems.
A real case
The situation
A company extracts a supplier's delivery note lines and the totals add up.
What you do
- Cross-checks two whole rows at random and the page break
What you get
A quantity turns up on the neighbouring reference, which the total was never going to reveal.
The situation
A table reads with its columns crossed.
What you do
- Reviews the extraction against the image
What you get
The figure ends up in its column.
The situation
The table splits across two pages.
What you do
- Checks it was read in full
What you get
No row is missing.
The situation
Only the total is extracted and the detail was needed.
What you do
- Defines which rows or columns matter
What you get
The extraction serves what is needed.
The situation
A skewed scanned table reads badly.
What you do
- Straightens it before uploading
What you get
Reading improves with no further tweaks.
The situation
Long tables are keyed by hand.
What you do
- Lets them be read and reviews the uncertain
What you get
Time goes on checking.
This article answers
- reads invoice tables badly
- extracting delivery note lines
- why does it pick the wrong row
- documents with many columns