Processing invoices and emails with AI

Why the inbox and the invoice pile slow you down

In most smaller companies the brake sits in the same two places. The first is a shared mailbox where everything lands: customer questions, delivery notes, supplier invoices, an invitation to a trade fair. Somebody has to pull that apart every morning and forward it to whoever it concerns. The second is the stack of incoming invoices that has to be retyped before it appears in the accounts.

Neither is hard work. Both are constant, both interrupt, and both always land with someone who was in the middle of something else. When that person is away for a day, the whole thing simply sits there. This is exactly the kind of work a language model is good at, on one condition: the result passes through human hands before anything leaves the building.

What comes in and what goes out

Two things run in production for us today, and both are built this way.

The first reads incoming email. Every message is read, sorted and summarised into an action item with a proposal: who is best placed to answer, what it is about, and what is expected. If a supplier invoice is attached, it is extracted and recognised, with supplier, amount, date and reference. The action item lands on a list where it can be followed up. Nothing is sent, nothing is posted.

The second follows a document along its whole route: from quote to invoice to the accounts. The data captured on the quote is reused on the invoice and travels on to the accounting package. What used to be typed three times is entered once and passed along.

What you see on your side is a list of proposals. Each one shows where it came from and what it is based on. You open one, check it, and click.

One thing matters here: your mailbox and your accounting package stay exactly where they are. We do not replace them and we do not ask your team to go and work somewhere else. The system reads along at the entrance and prepares things at the exit. Whoever works in the accounting package today keeps doing that tomorrow, with the difference that the fields are already filled in.

Why a person always makes the click

That click is not an interim step we quietly remove later. It is the reason the system is allowed to run in production at all.

A language model can misread a supplier name. It can treat the amount on a credit note as an ordinary invoice amount. It can file a letter from a solicitor with the supplier messages because the shape of it looks similar. Such errors are rare and they cannot be engineered away. Anyone promising they will disappear is selling something other than what exists.

So we put the model where it is strong: reading, recognising, sorting and proposing. The decision stays where it belongs. Sending to the customer, posting to the accounts, paying: that happens on your click, not a model's. That click is one action, against retyping the whole document.

There is a second reason. Every click records who took the decision. When a question comes back later from the accountant, or a supplier disputes something, what matters is who let it through. As long as that step sits with a person, the question has an answer. Automate the step away and the question stays while the answer disappears.

We charge on the scope of one process, and that scope stops at the proposal on purpose. It is not a technical limit. It is a choice about who stays accountable for what leaves the building, and that question only gets more pressing as more companies start working with these models.

What never happens without a check

We would rather spell out what does not go out on its own.

No reply reaches a customer without a person having read it. No invoice is posted without somebody confirming the proposal. We prepare no payments and we delete nothing. A message the model cannot place with enough confidence is not discarded and not guessed at: it goes on the list marked as unclear, so that it is guaranteed to reach a person.

Everything the system does is written to an activity log: which message came in, what was extracted from it, which proposal followed, and who confirmed it. That log is not there to cover us. It is there because a company working with AI today has to be able to show who decided what. Your accountant will ask sooner or later, and possibly your insurer too.

Where this already runs

The two applications above run every working day in production for us, on our own mailbox and our own accounting package. We name no clients and no numbers here. Figures about processed volumes say little about your situation, and a client name on a web page is not something we give away.

What does transfer is the shape. One source coming in, one list of proposals, one human click, and a log that explains afterwards what happened. That shape fits a quoting flow just as well as an invoice flow, and it is the shape we start every new process with.

Which of the two comes first at your company depends on where things jam. If the brake is the mailbox, that is where it starts. If the invoice stack is what sits waiting, that one goes first. Either way it stays one process, with a scope described up front. That is the same logic as any other project we take on: accepting two flows at once makes it hard afterwards to see which of them actually worked, and that is a question you will want answered.

If you want to know whether your own mailbox or invoice flow qualifies, one process is enough to start with.