Why the totals come out first time
The invoice total, the net amount, the VAT, the date and the document number are the easy fields, and the reason is a dull one. They always sit in the same spot on the page, and there is only one of each per document.
Why the line items are another story
The first problem is that you don't know how many there are. One invoice has three lines, the next has forty-seven and runs over four pages, and on every page the headings come back, and maybe a carried-forward total as well.
The second problem is that one item doesn't necessarily fit on one printed line. The description wraps and takes up two or three lines of print, while the code, the quantity and the price stay written only on the first. So whoever is reading has to work out where one item ends and the next one begins.
Then there are the lines that aren't items at all. The discount at the bottom, the supplier's note, the shipping charge, the order reference slipped in halfway down. Things that look like an item without being one.
And finally every supplier puts the columns wherever they please. One writes the code first and the description after, another the other way round, one has a discount column and another doesn't.
Each supplier, though, is consistent
The job is possible because every supplier prints its invoices the same way every time, since they all come out of the same program.
So you don't try to write a universal reader that understands any invoice in the world. You learn the layout of that one supplier, where it keeps the columns, how the heading is built, how it marks discounts, where the table ends and the footer begins.
Done once, that layout covers every invoice from that supplier, until they change the form.
This is also where the practical advice comes from. You start with the handful of suppliers who send you most of the documents, not with the one who writes to you twice a year.
You find the column by its heading, not by its position
The fragile way says, the quantity is the third column from the left. It works perfectly until the supplier adds a column, and from that day the system writes into the quantity field whatever it finds in the third column, which is now the price.
The way that holds up says, look for the heading that reads Qty and take what sits underneath it, and if you can't find that heading, stop instead of guessing.
It's the same logic that applies to Excel files and CSVs, and the reasoning in full is in The file arrives every month with the columns moved
The lines have to add up to the total
Once you have read all the lines you add them up, and that sum has to match the net amount printed on the invoice, which you had already read earlier, from the easy spot.
If it matches, you have proof that you didn't lose a line, that you didn't count one twice, that you didn't read 1.250,00 where it said 1,250, and that the page break didn't eat anything.
If it doesn't match, something went wrong, and the system stops and puts that document in a queue for a person. It doesn't try to sort it out on its own.
Say, just to show the arithmetic, that an invoice has three lines of 100, 250 and 40 euros, numbers made up here to show the method. The sum is 390. If the net amount on the invoice is 390 the document goes through. If it is 430, either a line of 40 was read twice or there was a fourth one you didn't see, and in both cases nothing gets recorded.
Stopping is the right behavior
An automation that reads documents is judged by what it does when it doesn't understand, not by how it behaves when everything runs smoothly.
A system built properly, faced with an invoice that doesn't add up, puts its hand up and leaves it there. An invoice that wasn't recorded you record yourself and that's the end of it, while an invoice recorded wrong comes back at you much later, with a credit note and a reconciliation that won't balance.
Anyone who tells you their PDF reader never gets anything wrong is selling you the sentence, not the product.
When the PDF isn't even needed
Before setting out to read the tables in a PDF, ask yourself the laziest question. Does that document already exist in a tidy form.
If the supplier also sends you the XML of the e-invoice, the lines are already in there, each one in its own field, and reading them is a completely different sport from interpreting a printout.
If instead the PDF is a scan, it's a photograph and it has to be interpreted before you can even think about columns, and the checks around it count for even more. That's covered in Why the computer sometimes misreads a document
What we need to tell whether your case can be done
To say anything serious about a job like this, all it takes is the suppliers who send you the most documents, a few of their invoices as examples with the lines inside, and the screen where that data ends up.
The documents tell you the rest, better than any meeting. If you want to start there, write to us from the Contact page