Invoice recognition is the technology that reads the data off an incoming invoice and turns it into a booking proposal: supplier, invoice number, date, amounts per VAT rate and a general ledger account per line. Reading the characters is the easy half. Deciding what they mean for your books is the half that determines whether the automation is worth anything. In this article you can read how it works, what it can and cannot do, and what to check before you choose a supplier.
Contents
What is invoice recognition?
Invoice recognition is software that extracts the data from an incoming invoice and maps it onto the fields your administration needs. It combines character recognition, which turns an image into text, with models that interpret that text: this number is the total, this one is the VAT, this name is a creditor you already have. The result is a proposed entry rather than a finished one, because the last judgement stays with a person.
How does invoice recognition work?
1. The invoice arrives
By e-mail, as an upload, from a mobile app or as an e-invoice over Peppol. The channel matters less than the format: an image needs reading, structured data does not.
2. Reading the characters
The image is straightened and cleaned, and character recognition converts it to text. For a UBL or Peppol invoice this step is skipped entirely, because the data is already structured. More on that in what OCR is and where it reaches its limits.
3. Recognising the fields
Now the text becomes meaning. Models locate the invoice number, the date, the payment term, the amounts per VAT rate and the individual invoice lines, and match the supplier to a creditor in your administration. Layout varies wildly between suppliers, which is why this step works on patterns rather than on fixed positions.
4. Coding and the booking proposal
A general ledger account and VAT code are proposed per line, and a cost centre where you use them. Self-learning models base that on your own earlier entries, so a supplier you book monthly needs less correction over time. You confirm the proposal, and the journal entry goes to your accounting package.
Recognition versus OCR
These are often used as synonyms and they are two different things. OCR turns an image into text. Invoice recognition interprets that text against your administration. A tool that only does OCR gives you a searchable PDF; a tool that recognises invoices gives you an entry to confirm. When comparing suppliers, that is the question worth asking, because both are advertised with the same words.
What it cannot do
- Judge whether an invoice is correct. Whether the goods arrived and the price was agreed is a human check, or a match against an order in your ERP.
- Read what is not there. A missing VAT number or an unreadable total cannot be recovered by better software.
- Handle every exception. Handwriting, credit notes and unusual layouts need a person, and that share does not go to zero.
- Replace your accounting package. Recognition sits in front of it and delivers the entry; the books and the payment run stay where they are.
What to check before you choose
Test with your own invoices rather than with a demo set, because accuracy depends on the suppliers you actually have. Check whether recognition goes down to line level or stops at the total, since line level is what makes cost centres and split VAT rates possible. Check the connection to your accounting or ERP package, because without it somebody still types. And ask what happens to your documents and their history if you leave, which is a question about the archive rather than about recognition. Storing invoices also falls under the European data protection rules, and retention periods are set per country.
Invoice recognition in TriFact365
TriFact365 recognises purchase invoices, sales invoices and receipts down to line level, matches the supplier to a creditor in your administration and proposes a general ledger account and VAT code per line. Over ninety per cent of fields on invoices with a normal layout are recognised straight away, and accuracy rises per supplier as the models learn from your entries. After your visual check the journal entry goes to your accounting package with the document attached; the payment run happens there. Read more about reading invoice data, about the route from receipt to journal entry, or about approval routes for invoices.
Frequently asked questions
Software that reads the data off an incoming invoice and maps it onto the fields your administration needs, producing a booking proposal with a general ledger account and VAT code per line. It combines character recognition with models that interpret the text.
OCR turns an image into text. Invoice recognition interprets that text against your administration, matching amounts to fields and the supplier to a creditor. OCR alone gives you a searchable document; recognition gives you an entry to confirm.
Above ninety per cent of fields on invoices with a normal layout is realistic, and it improves per supplier because the models learn from your earlier entries. Handwriting, poor scans and unusual layouts stay the exception that needs a person.
A UBL or Peppol invoice needs no character recognition, because the data is already structured. The coding still applies: which general ledger account and VAT code the lines belong to is decided the same way for both formats.
No. The proposal is prepared automatically and a person confirms it, after which the journal entry goes to the accounting package. Posting without a check moves the work to corrections afterwards, which costs more than the confirmation.
