Every month there is a stack of purchase invoices. Someone retypes the invoice number, looks up the supplier, checks the btw (Dutch VAT) rate and posts the line. That is not thinking work — it is retyping work. And it is exactly the work that software vendors have been promising for two years that artificial intelligence would take over.
The question you ask as a controller or director is more concrete than the promise: what does it take over, and what does that deliver? Most articles answer that second question with a percentage. This one does not. There is no public research into the return on AI in bookkeeping in the Dutch mkb — small and medium-sized businesses — that you can check for yourself, and a figure you cannot verify is not an argument but decoration.
What you do get here: precisely what Odoo automates according to its own documentation, where the limit lies, and a calculation method with which you work out the ROI for your own administration yourself. doo.FINANCE is an Odoo Gold Partner and sets these processes up at Dutch mkb companies — this is what we see working in practice, and what we do not.
What "AI in bookkeeping" actually means in Odoo
In accounting software the word AI covers three completely different things. Confusing them is the main reason expectations are not met.
Document recognition. Odoo reads a PDF or a scan of a purchase invoice and fills in the fields of the accounting record. The documentation calls this document digitization and describes it as converting paper or digital documents into records in a database, using OCR and artificial intelligence.
Automatic reconciliation. Odoo links bank transactions to open invoices and payments. This is not AI, and Odoo does not call it that anywhere: it is fixed matching rules plus reconciliation models that you set up yourself.
An assistant inside the database. Since Odoo 19 there is an AI assistant in the interface (Ask AI) that answers questions, improves texts and opens views. What it does not do is stated just as clearly: change data.
Anyone who keeps these three apart sees immediately where the time saving sits — and where you need better data instead of smarter software.
Document recognition: from PDF to posted purchase invoice
This is the feature with the most direct time saving: it is the only one of the three that genuinely replaces typing.
You switch the feature on under Accounting > Configuration > Settings, section Digitization: enable Document Digitization and choose whether purchase invoices are processed automatically or on request.
Documents come in in three ways:
- drag them into the purchase journal you want on the Accounting dashboard, or click Upload;
- through a journal email alias — by default
vendor-bills@followed by your alias domain. Every PDF in the attachment automatically becomes a new draft invoice; - from a scanner that emails to that alias.
Note: through a journal email alias, Odoo processes only PDF and XML files. JPEG files — the photo of a receipt — have to come in through the Documents app.
After that the sequence is fixed: click Digitize document, wait for the blue banner, click Refresh, check and correct the fields, and only then click Confirm to post.
Which fields Odoo recognises — and which it does not
The documentation is unusually precise about this. Recognised are:
- in the header: the supplier, the invoice reference, the invoice date, the payment reference, the recipient's bank account, the due date and the currency (in a multi-currency environment, provided that currency is active);
- on the lines: the description or label of the product, the quantity, the unit price, btw (provided the rate is active), the amount excluding btw and the total.
Two things that are not on that list matter more to the mkb than what is.
First: the general ledger account and the cost centre are not recognised. The coding decision — where does this cost belong — stays human work, or comes out of a rule you set up yourself.
Second, and specific to the Netherlands: the payment reference is only recognised in the Belgian structured format +++xxx/xxxx/xxxxx+++. A Dutch betalingskenmerk, the Dutch payment reference, falls outside that. Anyone who needs that reference in order to reconcile later takes it from the XML or fills it in by hand.
Automatic posting, with a brake on it
Odoo can also post recognised invoices definitively by itself, but per supplier. On the supplier's contact form, tab Accounting, there is the option Auto-post bills with three settings: Always, Never, and — the most interesting one — Ask after 3 validations without edits.
That middle setting means: if the third uploaded invoice from this supplier is confirmed without a single correction, Odoo asks whether you want to switch automatic posting on. So automation has to earn itself first, supplier by supplier. That is exactly the right order.
Conditions: Digitize automatically has to be on, the supplier has to exist in the database already, and every invoice has to carry an invoice date.
The cheapest automation is the automation you do not need
Recognition is at heart a workaround for a problem the Netherlands has largely solved already: documents that arrive as an image instead of as data.
Odoo is itself an access point and an SMP on the Peppol network. The Netherlands is on the list of countries where registration through Odoo is possible, NLCIUS is a supported sending format, and registration is free — in Odoo Community too. Incoming Peppol documents are collected several times a day and appear as draft invoices in the purchase journal you have set.
And then the sentence from the documentation that settles the financial argument in one go: XML files consume no OCR credits, because they contain structured data that can be processed directly.
So every supplier you invoice through Peppol costs no credit and produces no recognition error. For a Dutch mkb company that is the fastest return in this article — and it is not AI.
Reconciliation is clever, but it is not AI
The documentation puts it soberly: thanks to the standard matching rules and the adjustable reconciliation models, Odoo selects the matching entries automatically wherever possible.
The rules are public and predictable:
- If there is no partner on the transaction, the label of the transaction is compared with the number, the customer reference, the invoice reference and the payment reference of existing invoices, purchase invoices and payments.
- If there is a partner on it, Odoo matches on amount, in this fixed order: the exact match, then the match with an early-payment discount, then the amount that appears in the label.
On top of that there are reconciliation models for what comes back every month. The example from the documentation is recognisable: an outgoing transaction of €103 against a purchase invoice of €100; the Bank Fees model creates the €3 counter-entry.
This behaviour does not get better the more data it sees — it gets better as your data gets better. A payment reference on the invoice and a partner on the transaction do more for your reconciliation rate than any model. That is also exactly where many projects go wrong: the pitfalls of Odoo implementations rarely sit in the software and almost always in the configuration.