There’s a conversation we keep having with IFS finance teams. They’ve invested in OCR. The PDFs get scanned, the data comes through cleanly, and yet the AP team is still spending most of the week clicking through invoices – fixing coding, second guessing GL accounts, chasing the right approver.
It’s a strange place to land after a serious software investment. It’s also usually the moment finance leaders start asking a more difficult question: if we’ve automated invoice capture, why does the workflow still feel so manual?
The real answer is that OCR was never going to fix that part. OCR is a digitisation tool. It turns an image into structured data IFS can read. That’s a useful job, but it’s a narrow one. Calling OCR “AP automation” is a bit like calling a calculator “accounting” – the right ingredient, the wrong claim.
Where the workflow actually breaks
The slowest, most expensive part of AP isn’t capturing what’s printed on the invoice. It’s everything that has to happen after capture: deciding which GL account the cost belongs to, which cost centre carries it, which IFS tax code applies, which project it should be allocated to, and who needs to approve it.
None of that information sits on the invoice your supplier sent. A vendor will never put your internal GL codes on their PDF. They don’t know your cost centre structure. They have no view of your approval matrix. So no matter how well your OCR reads the document, the moment the data lands in IFS, a human still has to make the coding and routing decisions – invoice by invoice, line by line.
That’s the gap. And it’s where most “automation” projects come to a standstill.
What actually closes the gap
If OCR is the eyes, the missing piece is the brain – something that can look at the captured data and make a confident call on coding and routing.
This is where AI built specifically for invoice coding comes in. It doesn’t try to read better than OCR. It reads your history instead. It studies how your team has coded thousands of past invoices in IFS (which suppliers tend to map to which accounts, which costs flow to which centres, which invoices go to which approver) and starts predicting the answers for every new invoice that comes in.
Done properly, this is the part that finally feels like automation. GL accounts populated. Cost centres assigned. Tax codes selected. The right approver in the routing slot. Free-text fields filled in where the model is confident. Exceptions surfaced where it isn’t.
The stack that works
A genuinely automated IFS supplier invoice workflow isn’t one tool; it’s a short chain of them, each doing a different job.
OCR (or EDI, where you have it) ingests the invoice and turns it into something IFS can read. A specialised coding AI sits on top, filling in the blanks the invoice itself can’t supply and learning continuously as your team posts and corrects. IFS Finance is the destination, where a fully coded, properly routed invoice arrives ready to be authorised and posted.
It’s not a more complex stack than what most teams already run. It’s just a more honest one.
The shift
If your team is still spending hours fixing coding after the OCR has done its bit, that’s not a sign your software has failed. It’s a sign you’ve hit the ceiling of what OCR can do, and that the next layer simply hasn’t been added yet.
That next layer is where touchless AP actually starts.
