Enterprise AI
The model reads the invoice, accounting approves it
Invoice entry is one of the most tedious jobs in procurement. A supplier invoice arrives and someone types the date, amount, VAT and tax number into the system field by field. We started using the new OCR models we rolled out internally for exactly this, and the difference was clear from day one.
The flow is simple
We upload the invoice. The model reads it, pulls out the supplier, date, invoice number, amount and VAT, and fills in the matching fields. The accounting team looks over the fields, fixes anything if needed and saves.
Uploading, the model reading it and checking the fields took 8.1 seconds in total for one invoice. Having the details we used to type by hand ready in seconds made our work a lot easier. And it is not only about speed; a boring, error-prone task simply goes away.
Why classic OCR is not enough
Classic OCR extracts the text on an invoice, but it does not know which number is the grand total and which one is VAT. You end up writing rules for every supplier's template. The rules grow with every new supplier, and after a while maintaining them becomes a job of its own.
Vision language models read the invoice as a whole, like a person would. They can tell the total from the VAT and return the result field by field. The two models we rolled out cover both ends of this: Qwen3-VL-Instruct for doing OCR directly with the model without a separate document parser, and PaddleOCR-VL 1.6 for scanning and recognition at a lower cost.
The data never leaves the company
For me this is the best part. The models run in-house, and invoice data is processed without going to an outside service.
An invoice carries supplier details, prices, the tax number and sometimes an IBAN. Sending that to an external API just to make things faster is not an easy call for most companies. With the model running inside, that debate is settled up front and the conversation is about speed and accuracy.
Why accounting still checks
Because accounting owns the record, not the model. The model reads very well, but it can also read something wrong while looking confident: a faded digit, a comma mixed up with a dot, an invoice with two different VAT rates.
So we do not use the model in place of approval. The model fills in, a person approves. We get the speed and the record is still checked. The first number I would watch is not the 8.1 seconds, it is how many fields accounting had to correct.
Do you need this if you have e-invoices?
In Turkey a large share of invoices arrive as e-Fatura or e-Arşiv, and those already carry structured XML data. OCR really pays off on invoices that arrive as PDFs, as scans or from suppliers abroad.
So the model does not have to read every invoice. Use structured data when you have it, let the model read when you do not. It looks like a small task, but it is done many times a day. In my view that is exactly where AI pays off fastest inside a company.