SHORT ANSWER
Language models with image support read invoices and bank statements without needing a template for every format. A properly built process has four stages: reading the document, enforcing a fixed data structure (e.g. JSON with a schema), automatic validation — totals, dates, account numbers, NIP tax IDs — and a manual review queue for low-confidence items. Without validation, automation generates accounting errors faster than a human can catch them.
- Older OCR tools required a template for every document layout; multimodal models do not.
- It is worth enforcing output as a structure with a defined schema, not free-form text.
- Control totals catch most reading errors without human involvement.
- Low-confidence items should go to a review queue, not straight into the ledger.
- Each extraction must be linked to the original file and page for auditing.
Why older OCR tools were a pain
Traditional tools had to be trained on each layout separately: invoice number here, amount here, date here. All it took was a supplier changing the template, and everything fell apart.
A multimodal model looks at a document like a human: it understands that “Total amount due” is the final amount, even if it appears somewhere other than usual.
Trust is built on checks, not faith
In the bank statement system we built for an accounting firm, no item moves forward unless the opening balance plus transactions equals the closing balance. It is one simple rule that eliminates most silent errors.
Then there are format checks: account number, NIP tax ID, date within the accounting period. Boring, cheap, effective.
A human at the end, but only when there is doubt
The goal is not to eliminate the human, but to save them 95% of the clicking. If the system flags twenty items for review instead of two thousand, a full day's work takes half an hour.
It is important to be able to view the original document excerpt for each item with one click. Without that, verification takes longer than manual transcription.