Webinar recap: from rules to self-learning AI in IFS

Webinar recap: from rules to self-learning AI in IFS

This is a recap of our September webinar for IFS users. Miikka Savolainen, our COO, and I started with the bigger picture. How widely do Nordic companies already use AI, and where in finance is it being put to work? Accounts payable leads the way. Yet one step is still largely manual, and that is coding non-PO invoices. From there we covered why rules only reach part of that work and how self-learning AI codes the rest inside IFS. Below you’ll find the recording and the key takeaways, including the best questions from the audience.

Why is coding still where the time goes?

Most IFS customers have already automated a good part of their AP process. Data capture is largely solved: OCR, and more recently AI-based OCR such as IFS’s own new solution, has been reading invoice data reliably for years, and e-invoicing keeps growing.

Coding is a different story. Somewhere between 85 and 100% of non-PO invoices are still coded by a person: GL account, cost centre, project, tax code and every other dimension. Including corrections and finding the right approver, that comes to roughly four to ten minutes per invoice. Multiply that by your annual non-PO volume and you have the size of the opportunity.

The minutes are only part of it. Coding quality varies from person to person, which shows up later in reporting. Every invoice waits for someone to code it, which stretches the invoice cycle. And when volume grows, the answer is usually another hire rather than more capacity.

Rules still work, but only on 5 to 15% of invoices

This was an important point for us to make: templates and rules still do a good job, and we recommend keeping them. For recurring, predictable invoices like rents, leases, utilities, telecoms and subscriptions, a supplier-based template works well.

In practice, though, rules typically cover around 5 to 15% of non-PO volume. Miikka explained why, and it has nothing to do with poor implementation. It is simply how business works:

  • The long tail. Most suppliers send invoices only now and then, and a template for each one doesn’t make sense.
  • One supplier, many codings. A single logistics invoice can include freight, warehousing and delivery, each coded differently.
  • Constant change. New suppliers, cost centres, projects and reorganisations all mean new or updated templates.
  • No learning. A correction made by an accountant stays a one-time fix.

That is where AI comes in. With self-learning AI, around 85 to 90% of non-PO invoices are coded automatically, rules keep handling their share, and the remaining invoices go to your team for a quick check. Every correction becomes training data, so the model keeps improving.

Why AP is the natural next step for AI in finance

The market data points in one direction. The Nordics are ahead of the EU average in AI adoption, and among large Swedish companies adoption has climbed from 38% in 2023 to 72% in 2025. The question is no longer whether to adopt AI, but which process comes next.

Finance is already the third most common area for AI use, and accounts payable is where finance AI is most mature, because that is where the volume is and where the return comes fastest. Interestingly, in a survey of nearly 800 AP and finance leaders, line-level coding was the least adopted AI use case in AP, at 27%. In other words, the most time-consuming step is also the one with the most room left, and moving early is still a real advantage.

Miikka summed up why coding is such a good fit for AI in five points:

  1. Volume. Lots of invoices means lots of data.
  2. Training data already exists. Your coding history is already in IFS.
  3. A built-in feedback loop. Every approved invoice teaches the model.
  4. It works inside your system. Nothing moves outside your existing setup.
  5. No process change. The same reviewers, the same approvers, the same flow.

How the AI learns your way of coding

This part answered many of the questions in the chat. The AI is trained once, during implementation, on around six months to a year of your historic invoices and coding data. It learns how your organisation codes invoices and why, including differences between countries or legal entities.

Once connected to IFS, it reads every field of each new non-PO invoice, both the image and the XML, and predicts every dimension separately, with multiple coding lines when needed. Each prediction comes with a confidence level. If the AI isn’t sure enough, the invoice goes to exception handling and a person fills in that field.

Invoices are then reviewed and approved in IFS just like today. After approval, the final coding flows back to the AI as feedback. One participant asked how quickly it learns from a correction. Miikka’s answer: typically after a couple of corrections, the AI adjusts its behaviour.

The key difference to rules is what the system looks at. A rule usually triggers on the supplier and perhaps a reference number. The AI reads the whole invoice, much like a person would, and combines it with your coding and approval history. That is why it also handles suppliers who send many different kinds of invoices.

Everything stays in IFS

Your team keeps working in IFS, with no new user interface. The coding values simply appear in the IFS posting lines. The AI also suggests the right reviewer and approver, which cuts down the internal chasing that so many AP teams know well.

On the technical side, older IFS versions connect via SFTP, with predictions written into the invoice XML that IFS reads in. IFS Cloud connects through the IFS APIs. Very little customisation is needed, and it is not a big IT project. Snowfox supports everything from IFS version 9 to IFS Cloud.

Across our customers, we typically see an 80 to 90% automation rate for non-PO invoices, around three times higher efficiency with the same team, fewer late payment fees, more consistent coding and a happier AP team.

Nordic Paper was one of the first IFS customers to take Snowfox into use, and they have paved the way for many others. As Emma Rienas Sandin, finance manager at Nordic Paper, put it: “Snowfox has made a positive difference to our AP process.” Since our global ISV partnership with IFS started last December, we have grown to over 15 IFS customers, with new implementations starting all the time.

Questions from the audience

A few of the questions are worth repeating here, because we hear them often:

  • Does Snowfox replace our OCR provider, such as Pagero? No. OCR reads the invoice and extracts the data. Snowfox does the coding, which is information that isn’t on the invoice at all. For IFS users we actually recommend IFS’s own new AI-based OCR.
  • Does it read both the PDF and the XML? Yes, along with other image formats and, when it improves accuracy, attachments.
  • What about work orders and projects that change all the time? We regularly update the active work orders and project numbers to the AI, so it only predicts values that are currently valid.
  • How does it handle new suppliers? The AI reads the invoice content, including line data, and uses your history of similar purchases, even from other suppliers.
  • How is it priced? A monthly fee based on the non-PO volume the AI handles.

The best way to know is to test it on your own data

We closed the webinar the same way we close most conversations: you don’t have to take our word for the accuracy. With our free proof of value, you share three to six months of historic invoices with coding and approval data. We train the AI on 80% of it and let it code the remaining 20% as if they were brand-new invoices, then compare the predictions against your actual values at dimension and invoice level. The result shows the accuracy you would start from on day one, with no changes to your IFS environment.

If your team is still coding non-PO invoices by hand in IFS, we recommend watching the full recording at the top of this post. And if you want to know what automation rate your own invoice data would reach, book a short conversation and we will run an accuracy test on your history.