# The whole stack goes through the scanner once

> How Invoicio splits a scanned stack of invoices into separate documents, extracts every field and matches the payments. Its prices are published.

Source: https://redbumerang.com/en/case-studies/invoice-processing/

Our own products / accounting

An accountant puts the month through the feeder in one pass. Conventional invoice OCR reads that file as a single document, so ten invoices become one wrong record.

*Red Bumerang’s own product. Figures counted from production, 6 September 2026. Users anonymised.*

<!-- anchor: problem -->

## The problem

An accountant's month-end was gated behind typing.

A firm keeping the books for thirty client companies receives what accountants have always received: an email folder, a shoebox, a stack of paper. Every document in it has to reach the accounting system — supplier, invoice number, issue date, service date, due date, net, VAT rate, VAT amount, gross, payment reference, currency. Ten or more fields, several hundred documents per company per month, thirty companies.

The bottleneck was reading, not thinking. An accountant's actual expertise is whether a cost is deductible, which period it belongs to, whether the VAT treatment is right. All of that sat behind hours of transcription that any careful person could have done.

Three things went wrong underneath that, and each costs real money.

The same invoice gets booked twice. It legitimately arrives three ways — emailed by the supplier, printed and scanned by the client, and again in the monthly paper stack. Catching that by eye across several hundred documents is unreliable, and a double-booked cost is an error in the books.

Bank reconciliation was a visual comparison of two lists that never align. Missing or mistyped payment references, rounding differences, one payment covering several invoices. Monthly, by eye, line by line.

And the tools meant to solve this fail at the first step. An accountant does not scan documents one at a time. They put the whole stack through the feeder in one pass. Conventional invoice OCR treats that file as a single document — so ten invoices become one wrong record. The tool assumes a working habit that no accountant has.

<!-- anchor: built -->

## What we built

Invoicio reads the stack, splits it, extracts every field, and matches the payments — and nobody types anything.

The scanner habit did not have to change. 189 multi-document scans were separated into 2,086 individual documents, the largest single file containing 71 distinct documents. Of the 6,259 documents in the system, 5,094 arrived inside a stack — that is the normal case here, not an edge case.

A phone photograph is valid input. So is a scan with no readable text layer, and so is a bank statement that a bank emits only as a picture of a printout.

Then the numbers that describe what changed:

- **Documents processed** — 6,259
- **Created by someone typing them in** — 0
- **Duplicate submissions caught and blocked** — 462
- **Bank transactions imported** — 2,253, across every bank the clients use
- **Payments matched to invoices automatically** — 604
- **Accounting periods locked and frozen** — 160
- **Tax-book entries reconciled** — 9,804

Zero manual entries is the number that matters. People still review and correct individual fields. Nobody transcribes a document from scratch.

- **Languages read** — Slovenian, Croatian, German, English

<!-- anchor: uncertainty -->

## The system is built to say "I am not sure"

This is the design decision the whole product rests on.

A system that always produces an answer will eventually write a confident wrong number into somebody's books — and in accounting, nobody finds out until the year-end audit. So this one is built to stop and ask.

Every document carries a confidence score. Arithmetic is checked independently of whatever the model thinks: net plus VAT must equal gross, and the totals are reconciled against the totals printed on the document itself. A document that is confident and internally consistent goes to the books. Anything else goes to a person.

Two smaller decisions follow the same logic. The extraction runs on a more expensive, more capable model than the job appears to need — because the cheaper one invented plausible values on ambiguous fields, where the better one declines to answer. Abstention is worth paying for. And document splitting runs at zero temperature, because where a stack divides is a fact about the pages, not a choice.

<!-- anchor: where-ai -->

## Where the AI is, and where it deliberately is not

Five steps use a model. Everything involving arithmetic or identity does not.

A model reads the image, decides where one document ends and the next begins, spots several invoices printed on a single sheet, extracts the accounting fields, and reads bank statements that arrive as pictures. Each of those is unstructured input where a person would otherwise have to look.

Everything provable is deterministic. Duplicate file detection is a hash comparison. Bank statements in a structured format are parsed, not read — exact, free, and preferred wherever the format allows. Arithmetic validation, tax-book reconciliation, period locking and export are ordinary code.

Including the step everyone assumes is AI. Matching payments to invoices is reference extraction, string similarity on supplier names, and rules about amounts and dates. No model touches it.

The principle, as the system actually applies it: a model is used where the input is unstructured and a human would otherwise have to judge it. Arithmetic and identity are never delegated to one.

<!-- anchor: origin -->

## It started with our own books

Invoicio.pro was not built as a product. It was built because we needed it.

It began as a command-line tool over a local database, doing the books for one company: ours. An accounting firm saw it working and asked whether they could use it. It is now a Red Bumerang product, sold on its own — which is a different thing from the client work in the rest of these case studies, and worth saying plainly.

Four months from the first commit to thirty-four companies across Slovenia, Croatia and Slovakia, with three accounting firms using it to run their clients' books.

We think the origin matters. A product built to win a market gets the features someone imagined a buyer would want. This one got the features that stopped us being slow at our own books, and then the features an accountant asked for while using it on real client work in a real VAT season.

One detail says more about that relationship than any feature list: releases wait for the accounting firm to be idle. During VAT season, a five-second restart in the middle of a session is not acceptable, so deployment is gated on explicit confirmation that nobody is working. The software ships around the accountant, not the other way round.

<!-- anchor: cost -->

## What does it cost?

Published, per month, excluding VAT. Fourteen-day free trial, no call required.

- **Business — a company doing its own books** — €25 / month
- **Accounting firm — books for multiple client companies** — €59 / month, plus €5 per client company

To make the middle tier concrete, since it is the one that carries the most work: an accounting firm keeping the books for thirty client companies pays €59 plus thirty times €5 — €209 a month, around €7 per company. That is the whole cost of not typing several hundred documents per company per month.

We publish this because the alternative is asking you to book a call to find out, and a price that has to be extracted from a salesperson is a price you are right to distrust.

- **Finance team** — €149 / month

<!-- anchor: method -->

## Method

What the numbers count. All figures were counted from the production database on 6 September 2026, covering 4 May to 6 September 2026 — roughly four months. 6,259 is every document in the system; 5,229 were read automatically and 1,030 migrated from the predecessor tool; 0 were created by manual entry. 2,086 documents were recovered from 189 files that each contained more than one document. 462 counts ingestion attempts rejected as duplicates, both identical files and the same invoice arriving under a different name.

What is not claimed. No extraction accuracy figure is published, because none has been measured against a labelled ground truth. The system records its own confidence — 5,266 of 6,259 documents at high confidence — but that is the model grading itself, and it is not presented as accuracy. The independent check is arithmetic: net plus VAT against gross, and against the document's own printed totals. That proves internal consistency, not that a supplier name was read correctly.

No time-saving or return figure is published either. No measurement of the manual process was taken before the change.

Scope. 34 client companies — 31 in Slovenia, 2 in Croatia, 1 in Slovakia — and 3 accounting firms. In production and in daily use.

---

<!-- anchor: next -->

## Bring us a process, or a market.

Every system here started as a conversation about work that was already happening — how it actually runs, where it costs the most, and what the order underneath it looks like. That is the first meeting.
