AI document processing in Hungarian: why an on-premise solution beats cloud AI

At most Hungarian companies, paperwork still happens the way it did ten years ago: someone opens the inbox, saves the PDFs, opens the accounting software or the ERP, and manually types in the invoice data — supplier, invoice number, date, net, VAT, payment deadline. The same goes for incoming contracts, purchase orders, delivery notes and forms. The process is slow, monotonous, and every manual entry is another opportunity for error.

AI document processing automates exactly this work. But how it does so matters a great deal. In this article we walk through what AI document processing actually is, what types of solutions exist on the market, where the cloud-outsourced approach falls short (using Microsoft Azure Document Intelligence and Copilot as examples), and why a Hungarian-optimised DocAI running on the company’s own server delivers measurably better results.

What is AI document processing?

AI document processing is a technology that uses artificial intelligence to automatically read, interpret and convert the information stored in documents into structured data. The input is typically an unstructured file — a scanned invoice, a PDF contract, a purchase order attached to an email — and the output is machine-processable, field-by-field data (for example JSON) that the back-end system can use directly.

It’s important to understand the difference between three frequently confused concepts, because it determines what a given system can actually do:

OCR (optical character recognition). This is the oldest layer. OCR can only turn pixel-based letters into machine-readable characters. If the invoice shows “1,250,450 HUF”, OCR turns it into text — but whether that’s the grand total, the VAT, or a line-item price, it does not understand. OCR “sees” but does not “understand”.

IDP (intelligent document processing). IDP builds on top of OCR. It recognises the document type (invoice, contract, purchase order, claim form), extracts the structured fields, validates the data, and hands it to the back-end system. This is no longer just seeing, but interpretation.

KIE (Key Information Extraction). This is the most valuable core of IDP: it extracts from the document precisely the fields the process needs, in the right structure. The quality of the KIE determines whether the system’s output is reliable enough to enter accounting or the ERP without a human rekeying it.

This distinction is crucial, because many solutions on the market call something “AI document processing” when it is in fact just a chat interface on top of the documents. We’ll come back to this.

The three types of market solutions — and where all three fall down

When a Hungarian SME, accounting firm or law firm goes looking for AI document processing today, they encounter three fundamental approaches. Each has its own logic — and each has a structural weakness worth seeing clearly before deciding.

1. The cloud hyperscaler service (Microsoft Azure Document Intelligence, Copilot)

The most obvious route is a large cloud provider’s ready-made API. Microsoft’s offering here is Azure Document Intelligence (formerly Form Recognizer), and for questions about documents, Microsoft 365 Copilot. Technologically these are mature products — the problem is not their capability, but their operating model.

The data leaves the company. Azure Document Intelligence is primarily a managed cloud service. Full on-premise (containerised) deployment is available only for certain models (Read, Layout); custom and pre-trained extraction models require a cloud connection for training. For an accounting firm’s client files, a law firm’s contract portfolio, or healthcare, banking or public-sector data, this is not a minor detail: alongside GDPR (especially Article 28 on data processing agreements) and data sovereignty expectations, the fact that a sensitive document is processed in a foreign cloud is often an outright deal-breaker.

The cost ticks up per page. Azure Document Intelligence is priced per page: Read OCR per thousand pages, the prebuilt models (invoice, receipt, contract, etc.) at a multiple of that, and custom extraction at an even higher rate. This means the solution is never “yours” — every processed page is another line on the bill, and the monthly cost grows in proportion to document volume, unpredictably. For an office with heavy document traffic this is a serious, recurring expense over the years, while in the end you hold no asset of your own.

There’s no Hungarian focus. Cloud OCR services support hundreds of languages — but that is exactly what makes them generic. None of them is optimised for Hungarian. The specific terminology and inflections of Hungarian invoices, contracts and official documents, and the handling of Hungarian date and amount formats, are inevitably a compromise for a global, all-purpose model.

There’s no ready-made workflow. Azure Document Intelligence is an API, not a finished application. There’s no built-in approval interface, no “human-in-the-loop” review UI — the company’s development team has to build that around it (typically from the Power Platform). This requires an Azure subscription, resource provisioning and key management. In other words, the “ready service” is really just the processing engine; building the usable product is a separate project.

And Copilot is not data extraction. Microsoft 365 Copilot, when it comes to documents, is essentially RAG-based question-and-answer: you ask it something in chat and get a free-text answer based on your company’s content — all of it, again, in Microsoft’s cloud. This can be useful for search, but it is not the same as structured KIE. A chat answer is not guaranteed to be complete, is not deterministic, and cannot be wired directly, field by field, into accounting. Invoice processing doesn’t need a “conversation” with the document, but reliable, structured data.

2. The consultancy/integrator project

The second route is to have an AI consultancy build the process for you in a custom project. The promise of this approach is tailoring: a workshop, KPI definitions, collecting a few hundred sample documents, then building the pipeline.

The problem is twofold. First, in the background these projects almost always rely on the same cloud engines (Azure, AWS, OpenAI) — meaning they inherit all the data-sovereignty and cost problems of the previous point, just with a consultancy layer on top. Second, the end result is a bespoke, project-style integration: expensive to build, and its maintenance also means ongoing consultancy dependency. In the SME segment, where the goal is fast, predictable return, this is rarely the most efficient model.

3. The SharePoint-based workflow + RAG chat

The third route is an enterprise document-workflow platform with an AI module bolted on. These typically build on an existing (often SharePoint-based) approval and records-management process, and their “AI” layer is mostly a RAG chat relying on a cloud large language model (for example OpenAI): it makes documents searchable and answers questions.

This can be excellent for a large enterprise’s policy and contract approval chains. But for two reasons it does not cover the real needs of Hungarian SMEs and firms. First, it’s a heavyweight, SharePoint-centric enterprise platform — too much for a 10–50-person accounting or law firm. Second, as we saw above: RAG chat is not KIE. Structured data extraction, the foundation of accounting and ERP loading, is secondary in this model — the emphasis is on search and the approval process, not on reliable field extraction. And here too, the actual AI remains in the cloud.

Why is DocAI different? On-premise, built for Hungarian

DocAI was built on the conviction that each of the three models above gives way at the same point: either the data leaves the company, or the Hungarian-language quality is a compromise, or the solution will never truly be yours. That is why DocAI’s motto is: AI that stays at the company.

The data stays at the company (on-premise)

DocAI runs on the company’s own infrastructure — as an on-premise appliance, or as a dedicated solution in a regulated environment. The document doesn’t go to a foreign cloud; processing happens entirely within the company’s boundaries. For an accounting firm or a law firm this is not only reassuring but often a compliance requirement: GDPR’s data-processing expectations, client confidentiality and data sovereignty are all satisfied, because the data doesn’t even physically leave the organisation.

A model optimised for Hungarian — and measured accuracy

DocAI doesn’t use a global, “know-it-all” cloud model, but a locally run language model tuned for Hungarian documents. And most importantly: we don’t just promise this, we measure it.

DocAI maintains its own KIE benchmark corpus assembled from Hungarian-language documents, and validates every model change against this test set with an automated evaluation harness (precision/recall/F1, plus a combination of LLM-judge and manual review). The current production KIE model, Qwen3.6, scored F1 = 0.975 on this Hungarian benchmark corpus, while a modern open model measured for comparison (Gemma) achieved F1 = 0.890 on the same corpus. The difference is not a marketing promise: it’s a reproducible measurement on Hungarian documents, whose methodology and results we have also documented publicly.

This is the kind of evidence a generic cloud service cannot show for Hungarian: they communicate a global average accuracy, while DocAI gives a concrete number measured on a Hungarian corpus.

Real KIE, not chat

DocAI is built for structured key information extraction (KIE), not for a chat window. It recognises the document type, extracts the defined fields in the right structure, validates them (is there such a supplier in the master data, does the sum of the line items match the total), and routes to human review in case of uncertainty. The output is deterministic, field-by-field, structured data that can be wired directly into accounting or the ERP — not a free-text answer that someone then has to reverse-engineer by hand.

Comparison table: the four approaches

Who is DocAI for?

AI document processing delivers measurable results fastest when there’s a high volume of repetitive documents and the data is sensitive. That’s why DocAI was built primarily for the following organisations:

Accounting firms, where masses of invoices, bank statements and receipts have to be entered daily — accurately, on deadline, while client data is confidential.

Law firms, where extracting and tracking the key data of a contract portfolio (parties, deadlines, amounts, obligations, risk points) is significant manual work, and where maintaining client confidentiality is not optional.

Regulated sectors and SMEs, where the data cannot leave the company’s infrastructure, but automating the back office (invoice processing, order management, records management) brings enormous savings in time and errors.

Frequently asked questions (FAQ)

What is AI document processing?
AI document processing is a technology that uses artificial intelligence to automatically read and convert the information stored in documents (invoices, contracts, forms) into structured data, replacing manual data entry. The input is an unstructured file, the output is machine-processable, field-by-field data.

What’s the difference between OCR and AI document processing?
OCR only recognises characters: it turns an image into text but doesn’t understand what is what. AI document processing (IDP) goes further: it recognises the document type, interprets its structure, extracts the specific fields (key-value pairs, tables), validates the data, and produces structured output.

Does AI document processing require sending my data to the cloud?
With cloud services (for example Microsoft Azure Document Intelligence) typically yes — the document is sent to the provider’s cloud for processing. DocAI, by contrast, runs on-premise, so the data doesn’t leave the company. For sensitive data (accounting, law, healthcare) this is often a compliance requirement too.

How accurate is DocAI on Hungarian documents?
On DocAI’s own Hungarian-language KIE benchmark corpus the current production model (Qwen3.6) scored F1 = 0.975, while an open model measured for comparison (Gemma) achieved F1 = 0.890 on the same corpus. We carry out the measurement with an automated evaluation harness and document it publicly.

Isn’t Microsoft Copilot enough for document processing?
Copilot is essentially RAG-based question-and-answer over your company’s content, in Microsoft’s cloud. It can be useful for search and summarisation, but it is not structured key information extraction (KIE): its answer is free-text, not deterministic, and cannot be reliably wired, field by field, into accounting or the ERP.

Why is a cloud AI document processing solution more expensive in the long run?
Cloud services typically bill per page: every processed page is another cost item, and the monthly spend grows in proportion to document volume, unpredictably. On-premise DocAI, by contrast, is an owned asset whose cost is predictable and does not recur for every single page.

Is DocAI suitable for small companies too?
Yes. DocAI was built specifically for the size and needs of Hungarian SMEs, accounting and law firms — not a heavyweight enterprise platform that requires a separate rollout project.

Summary

AI document processing is no longer an experiment but a live technology working on thousands of documents a day. The question is not “whether”, but how you adopt it. Cloud-outsourced solutions — including Microsoft Azure Document Intelligence and Copilot — offer mature technology, but they give way at three consistent points: the data leaves the company, there’s no real Hungarian-language optimisation, and the solution will never truly be yours.

DocAI reverses these three points: it runs on-premise, it is tuned and measured for Hungarian, and it provides real, structured key information extraction — not chat. If your company handles a lot of sensitive documents and you’re looking for AI document processing that stays at the company, let’s talk.