Ezura
EzuraInvoice Automation

Automation rules built from your accounting history

17 August 2026 · 6 min

When an accounting firm looks at invoice automation, the hardest question is rarely whether the reading works. The hardest question is how long it takes before the system works the way the firm already works. That is the right question to ask – it is exactly where rollouts stall.

Automation without rules is just scanning. For an invoice to arrive ready, the system has to know what you know: that this supplier's invoices always go to one department, that another supplier is always the same site, that a third one carries a VAT code that is not the standard one.

The cost of a rollout is not the fee – it is the rule list

Picture forty regular suppliers. Each one needs a decision on the department, the site, the product or G/L account, the VAT code. That is several hundred decisions somebody has to make and type in before any of the benefit arrives. In practice that work gets postponed, or done in a hurry – and then the first month looks worse than it should.

This is the objection that actually kills automation projects, and it has very little to do with how good the recognition is.

You already made those decisions – thousands of times

Here is the thing: none of those questions is new. Every one of them has already been answered – not in the document, but in your own books. Every entry from the past months shows which department you assigned that supplier's invoice to, which site you tagged, which VAT code you picked. That is not an assumption about your accounting. That is your accounting.

So at the start of a rollout we do not ask you to write that down. We read it from what is already booked and hand it back to you as proposed rules.

What the history shows

  • Which department a given supplier's invoices normally go to
  • Which site those invoices almost always carry
  • Which product or G/L account is used for those lines
  • Which VAT code applies – including the cases where it is not the standard one

When a repetition becomes a rule, and when it does not

Not every coincidence is a pattern. A supplier you have seen a couple of times does not get a rule – that is too little to call a habit. A supplier where you picked one department half the time and a different one the other half does not get a rule either, because that rule would be wrong every second invoice.

Only what repeats consistently in your history is proposed. Ten rules you trust are worth more than forty you have to check one by one.

One supplier does not always mean one behaviour

A common case a single rule cannot catch: the same supplier sends two completely different kinds of invoice. Rent goes to one department, utilities go to another. An averaged rule here would be worse than no rule at all.

Those invoices can usually be told apart by their number series – they look different to you as well. Where the history shows the series behaving differently, a separate rule is proposed for each series instead of one blended rule.

A list you review, not changes that simply happened

Nothing is applied silently. You get a list of proposals first: the supplier, what would be assigned, and how consistently it has been done so far. What you approve becomes a rule. What you do not approve does not exist. Rules you already have are not overwritten.

Reviewing takes far less time than building. Reading a list and agreeing with it is a different job from filling in an empty form forty times.

What the history cannot tell you

Sometimes a proposal cannot be applied: the supplier is not in your company list yet, or a code used in the history has no counterpart in Ezura yet. Those cases are skipped and named, not guessed.

In practice that is often the most useful part of the list – it shows where your classifiers have drifted apart, before that turns up in the books.

What this covers today

Today this reads Rivile GAMA history. We do it for you during the rollout and only with your go-ahead – there is nothing for you to run or configure, and every proposal is still yours to approve. If you work in another system, we build the first rules together with you from your real invoices instead: the same principle, a different source.

What it changes in the first month

Day one no longer starts with an empty rule list. It starts with a list that already reflects your accounting logic, and your job is not to create it but to correct what has changed since. The benefit shows up almost immediately rather than after two months of tuning – and the exceptions stay what they are supposed to be: exceptions.

How those rules work day to day:

Working in Rivile?

The full invoice automation flow:

Want to see what your history shows?

All articles