Can AI read our invoices and get them into the system without someone typing them?

Patriot Pipeline processes invoices in both directions, payable and receivable, and the input problem is identical in each: what arrives is a document, not data. PDF attachments by email, and scans. Between 5 and 20 a day.

That volume is worth stating plainly, because it is simultaneously the volume at which this is clearly worth automating and the volume at which almost nobody does. It is not enough to justify hiring somebody. It is far too much to be a rounding error. It sits in the band where it quietly consumes a share of one person's every single day and never becomes urgent enough to reach the top of a list.

The two input formats are not the same problem, either, and a vendor who treats them as one is telling you something. A PDF generated by a supplier carries a text layer, so the characters are already there to be read and the work is understanding the layout. A scan carries pixels. The characters have to be recovered before anything can be understood, and a crooked page or a bad photocopy degrades that recovery in ways no amount of layout intelligence recovers from. Any system that handles real invoice traffic has to deal with both, because real invoice traffic contains both.

• Vendor and invoice number. Identity. Which supplier sent it and which document this is, so a duplicate can be recognised as a duplicate rather than paid twice.
• Line items. The money, itemised rather than as a total, because a total is a number you can file and line items are something you can check against what was ordered.
• Job number, PO and part. The three that matter most for a contractor. Which job the cost belongs to, which authorisation it was raised against, and what was actually supplied.

Those last three are the difference between a parser and a novelty. An invoice read without them is an invoice somebody still has to code by hand, and the coding is most of the work. Getting totals off the page saves keystrokes. Getting the job number off the page is what puts the cost where it belongs.

Into the project financials platform, which is the system that already holds estimating, cost tracking and budget tracking. That destination is the difference between a demo and a tool.

Extraction into a spreadsheet demonstrates that the technology works and leaves a person carrying data from the spreadsheet into the system that actually matters. Extraction into the platform that holds the budget the invoice draws against removes the work rather than relocating it. If you are evaluating anything in this category, ask where the output lands before you ask how accurate the reading is.

Every field the parser produces can be checked against the document it came from in about a second. The vendor is either right or it is not. The invoice number is printed on the page. The job number either matches a job or it does not.

That is an unusual property, and it is the reason we tend to build this first when a company wants to find out whether any of this works before committing to something larger. Compare it with a system that drafts or decides, where being wrong is expensive and being subtly wrong is difficult to notice at all. Invoice parsing is the rare job in this category where the output carries its own proof, so you can trust it on evidence rather than on assurance.

It is also why this works as a first engagement rather than as the first phase of a platform. The scope is bounded, the input already exists, and you can tell inside a week whether it is doing the job.