Two to Three Person-Years of OCR, Replaced Over One Long Weekend

Why does invoice administration cost so much before volume ever becomes the problem?

Administrative work is one of the few costs that scales badly in both directions. A large enterprise absorbs it by hiring data entry clerks. A small company absorbs it by taking it out of the day of whoever happens to be responsible – which, in practice, means the person who should be doing something else. Either way the work is the same. Receive a document, read it, type its contents into a system, file the paper, prepare a payment, reconcile it later against a bank statement.

This article describes an accounting automation system VIS Solutions built for itself and runs in production today. It is a capability proof, not a scale claim. The point is the pattern, and the same pattern turns up in an enterprise finance department with two orders of magnitude more documents. The showcase runs a lightweight version of VISERA, VIS's accounting automation product. VISERA 2.0 Disruptor is the enterprise-scale version of the same idea.

VIS processes roughly 30 incoming invoices a month. That sounds trivial. Then you look at the distribution: on average, every day or two, something has to be recorded, paid, or prepared for the accountant. The cost is not the total hours. The cost is the interruption – a constant trickle of small, non-deferrable administrative tasks landing in the middle of work that needs concentration.

Why hiring an assistant does not solve administrative overhead

The first solution was the obvious one: a student assistant. VIS ran that way for about four years, with three students in sequence. The role covered all administration outside core business and sales – office supplies, cleanliness and maintenance, HR process administration such as tracking applications and sending thank-you notes, one-off form filling and delivery, EU project administration, and occasionally help with organising a meetup or the Christmas party. The last student worked three days a week.

It worked, until it didn't. Students have exams. They have the seaside in summer and skiing in winter. They get sick. And they have a grandmother in Bosnia.

The failure mode was always the same, and it was not the absence itself. It was the absence of state. One message, sent the evening before the day a student was due in: she was going to visit her grandmother in Bosnia for several weeks. The monthly papers were due, and there was no handover of any kind. So the work fell back on the founder, in a more chaotic and less structured form than if he had simply done it himself. Handovers which are not really handovers.

Reconstructing the state took several hours, always at the worst possible moment. No system recorded what had been prepared and what had not. So the only method was cross-referencing the two document types against each other: work out which bank statements were missing, work out which invoices were missing, and match them up. Whether the documents are physical paper or digital copies makes no difference to how long that takes.

RPA or an LLM? Invoice automation needs both, doing different jobs

The insight is a division of labour between two technologies that are usually discussed as rivals. RPA is good at deterministic mechanical work in interfaces that have no API. Large language models are good at reading documents that were never designed to be machine-readable. Neither replaces the other. Together they close the loop, and that pairing is what we mean by Intelligent Automation—the combination of screen-level RPA and document intelligence that VIS has implemented here.

The initial build took one long holiday weekend. The application has been evolving constantly ever since.

How does automated invoice data extraction work end to end?

Where do the documents come from? One intake point, the email inbox

Everything arrives by email – incoming invoices and bank statements alike. The robot downloads the documents from the inbox. That keeps intake uniform and avoids maintaining a separate connector for every source.

Which invoice formats actually need AI extraction?

Roughly half the invoices are domestic and effectively structured. An intermediary provides a link from which both the XML and the PDF version can be downloaded, so the data is already machine-readable.

The other half are foreign invoices arriving as PDFs, plus the genuinely worst category: physical paper. Fuel for the company car, a business lunch. Those get photographed with a mobile phone, and the LLM extracts the fields from the photo with reasonable accuracy.

How accurate is LLM extraction from a scanned or photographed invoice?

When the incoming data is not structured – a PDF or a scan – the flow calls an OpenAI LLM and gets back the structured data needed for further accounting processing.

Where it struggles is on codes rather than prose. On phone photographs, the most common confusion is numeric identifiers such as tax numbers. That turns out to be tolerable, for a structural reason: such codes carry a control digit calculated from the other digits, so a misread value can be recognised automatically. Whether the root cause is the OCR layer or the LLM is not established.

How do you enter data into an accounting application with no API?

The flow runs on Microsoft Power Automate Desktop, and the reason is the target system. VIS's accounting application is a very popular Croatian desktop product whose underlying technology is believed to date from the 1990s – something like MS Access plus Visual Basic. There are very few modern interfacing options. So the robot does what a person would do: it clicks and types into the interface, field by field.

This is worth stating plainly, because it is the most common reason automation projects stall in real enterprises. The system of record is old and closed. RPA is not a nostalgic technology choice here. It is the only bridge available.

Where does the human stay in the loop?

Once the invoices are entered, the accounting application itself generates the payment order. The robot is deliberately given no access to e-banking. That is where the human in the loop sits, responsible for paying the right amounts to the right vendors.

Why is there still a printer in the flow?

The flow also sends invoices to the printer, because the accountants say paper is a legal requirement. My own reading is less charitable and more practical: the paper most likely still serves as the source a human reads from before typing into their own application. Either way, it illustrates something real about automation in a regulated, multi-party process. You can automate your own side completely and still end up carrying documents around, because someone downstream has not.

Should you optimise the process before automating it?

The most transferable part of this showcase is not technical at all. Before automating anything, the process itself was restructured. Payments are executed twice a month, on working days around the 10th and the 25th, instead of whenever a new invoice happens to arrive. Batching removes the constant interruption and imposes structure on a process that previously had none.

This ordering matters as much as the automation itself. Automating an inefficient process does not eliminate the inefficiency, it relocates it – out of daily operations and into the maintenance of an unnecessarily complicated system. The complexity survives, now encoded in software that someone has to keep alive.

Can automating bank statements give finance a same-day trial balance?

Bank statements are also pulled from email and processed by RPA, and invoices are entered as they arrive. So VIS ends up with a parallel set of books running alongside the external accountant's.

The parallel books contain nothing the accountant's books do not. What they add is speed. If a bank asks for a trial balance, it can be delivered today, with data current to today. Through external accounting the same request could take a week, and the figures would still be a month old.

Payroll stays outside all of this for now, but it is the very next process to get automated. It is still a semi-manual data entry process.

How much manual work is left after the invoice flow is automated?

A full monthly cycle now consumes a few hours of human time – closer to three hours a month than to three days a week. What remains is the final check of the papers, physical delivery to the accountant, and creating invoices receivable for clients. Compared with the previous arrangement, the administrative load of a small team has collapsed into a short, predictable, twice-monthly routine. And the reconstruction problem – working out what was done and what was not – has disappeared entirely, because the system knows.

Why LLM extraction replaced two to three person-years of OCR/NLP development

The genuinely unexpected result was how easy extraction from unstructured documents turned out to be.

“What surprised me was the ease of extracting data from unstructured documents. The previous version of VISERA, our accounting automation software, took years to develop an OCR / NLP based solution for the same problem.

That earlier OCR/NLP solution represented an estimated two to three person-years of development. The equivalent capability, built with an LLM, came together over one long weekend. That comparison is why VISERA was reengineered into the current VISERA 2.0 Disruptor version instead of being improved incrementally.

What can invoice automation still not do?

Degraded paper remains unsolved, and probably unsolvable. A fuel receipt that has been exposed to the sun is difficult to read for a human and difficult to read for a machine. There is no model fix for information that is no longer physically present on the paper.

Physical logistics also stay human. When something has to be bought, delivered or collected, no robot does it. The answer there is again process design rather than automation: those errands get done on the way to work or during a break.

What does the enterprise version add over the internal showcase?

The showcase described here runs on a lightweight version of VISERA. VISERA 2.0 Disruptor is the enterprise-scale version of the same idea. The difference is not raw extraction capability. It is integration – the enterprise version adds ERP integrations, SAP among them.

Two deliberate scope decisions are worth noting. Volume is not the differentiator; an automated workflow does not care whether it processes tens or tens of thousands of documents. And approval workflows are intentionally left to the ERP, because that is where they belong. The automation feeds the system of record rather than trying to replace its governance.

What should a CFO and an IT lead take from this?

The CFO is the user of a system like this. The IT lead is the enabler. Both should draw the same conclusion, and it is less about accounting than about where human attention is worth spending.

“In the time of agentic automation, most manual data entry and clicking can be automated. Humans can then be used for control and accountability, instead of hiring dozens of data entry clerks.

It is natural for a person to move around and get things done, not to sit and do administration. That is what the agent makes possible. The mechanical reading and typing goes to software, the payment decision and the accountability stay with a human, and the errands get folded into the commute.

Division of labour: screen-level RPA versus LLM document extraction in one invoice flow

If your finance team is still manually entering invoices into legacy systems, you have a process that looks a lot like this one did. Extraction with AI, data entry with RPA, human control at payment – the pattern works at any scale. This is the first of the showcases we are publishing from our own back office, and the rest will include the architecture, the numbers, and the parts that still do not work. Subscribe to our VIS newsletter if you want to see how far this goes.