TL;DR: our OCR module reads your supplier invoices in PDF and does the data entry for you: supplier, number, dates, line details with quantities and prices, taxes applied. You review, you post. The analysis runs through the AI model of your choice, up to a local model that never leaves your network, and the final validation always stays human. The module's code is public.
On the 28th of the month, the pile is still there. Twelve, twenty, forty supplier invoices in PDF sitting in a mailbox, and someone on your team opening them one by one to retype the number, the date, the pre-tax amount, the GST, the QST, the total. It's the same ritual every month, and nobody has ever woken up motivated by invoice retyping.
Retyping: do the math
Time yourself once: a supplier invoice entered properly, with the tax breakdown and the right line details, takes five to eight minutes. At thirty invoices a month, that's about three hours of work that contributes strictly nothing: no analysis, no decision, just moving numbers from a PDF into fields.
And those three hours carry a very real risk: two digits swapped in an amount, a tax split wrong, and your tax report inherits the problem. Manual entry isn't just slow, it's fragile.
The concept
You create the supplier invoice as a draft, drop the PDF onto it, and a "Scan OCR" button launches the analysis. A few seconds later, the fields are filled in: supplier, invoice number, dates, currency, and the line details with their quantities and prices. When it recognizes one of your products, the module attaches it to the line instead of leaving free text there.
A word about taxes, because the nuance matters: the module does not copy the amounts printed on the invoice. It builds the lines, applies your default purchase tax to them (in Quebec, the GST+QST group) and lets Odoo recompute the totals. That is sturdier than a transcription, but it means an out-of-province, HST or zero-rated invoice needs your eye: the default tax will not be the right one, and correcting it is on you.
The module recognizes your suppliers even when the name on the invoice doesn't exactly match your records: it cross-checks the business number, the email domain, the phone number, the history of your previous scans. And every scan shows a confidence score. Mind what it actually is: the model rating its own reading, not a measure of accuracy. Treat it as a reading order, not a green light.
Then comes the non-negotiable principle: you validate. The scan posts nothing. It fills in a draft, and nothing becomes an accounting entry until you confirm the invoice yourself, the usual way in Odoo. A scheduled job also runs every hour and scans ahead, twenty at a time, the pending invoices that have a PDF: in the morning they are already read, and all that is left is to review them and confirm them, in bulk if you like.
What about services like Dext?
Cloud services like Dext (formerly Receipt Bank, now part of IRIS Software Group) have been doing this job very well for years, on a monthly subscription whose price is capped by the volume of documents processed: go past the month's quota and your documents stop being read until the next billing date. The difference is structural: with those services, your invoices live on their platform, and your accounting in another system, with a sync in between.
With the module, everything happens in one place: the invoice arrives in your Odoo, gets read in your Odoo, and becomes an entry right where your accountant already works. No middle platform to pay for, sync and document in your subcontractor registry. If you're still shopping for the accounting system itself, we've also compared open-source and commercial accounting solutions.
Let's talk frankly about AI
The PDF analysis is done by a large language model, called from your own server, and the document is sent to it for the length of the read. You choose the provider: Anthropic, OpenAI, or an OpenAI-compatible local model (Ollama, llama.cpp) running on your own hardware, which sends nothing outside your network. The API key, for its part, is encrypted at rest in your database.
When you go through a commercial provider, it is the terms of its API that rule out training on your documents: that's one of our selection criteria, not a footnote. One precision that matters: those terms cover the API, not the same provider's consumer plans, which can be used to train its models.
For the vast majority of supplier invoices, amounts, taxes, product descriptions, it's a very reasonable trade-off. For genuinely sensitive documents, two options: exclude them from scanning and enter them by hand, or run the whole module on a local AI model hosted on your own hardware. We'll sort it out based on your situation.
Other limits worth knowing: the module reads PDFs, up to 20 MB, and not photos of invoices taken with a phone. Some scans fail, and the module tells you so rather than guessing. And it doesn't learn from your corrections from one time to the next: every scan starts fresh, with the same instructions and nothing but the PDF at hand. The history it uses to recognize a supplier, for its part, never leaves your Odoo database: it's a local lookup, never sent to the model.
To start on the right foot:
- Start with your five biggest recurring suppliers: that's where the hours come back.
- Keep the human validation, even when the confidence score is high: it's your accounting.
- Keep an eye on out-of-province invoices: the tax applied by default will not be the right one.
- Identify in advance the sensitive documents to exclude or route to a local model.
How it works in our own shop
Our own supplier invoices go through this module. The reflex changed within a few weeks: we no longer "enter" an invoice, we scan it, review it, confirm it. The accounting month-end got shorter by the same amount, and the typos in numbers and dates are gone, quite simply because nobody retypes them anymore.
If your month-end still looks like a pile of PDFs to retype, let's explore it together.
Sources
- bf_invoice_ocr: the module's code, on our GitHub repository
- Dext: the reference service in this category, with pricing tiered by document volume
- Anthropic's commercial terms: "Anthropic may not train models on Customer Content from Services"
- Update to Anthropic's consumer terms: the distinction between consumer plans and API use
- Our modules page: the invoice OCR module's card