AI in your bookkeeping: what Odoo automates (and the ROI for the mkb)

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.

Forecasting: what Odoo actually predicts

Odoo has a standard Executive Summary report containing a line Short-term cash forecast. The definition is stated there literally: how much money is expected to come in and go out over the coming month, namely the balance of your sales account for that month minus the balance of your purchase account for that month.

That is a subtraction, not a forecasting model. No trend, no seasonal pattern, no payment behaviour per customer. Anyone who presents it differently is selling something that is not there.

What is usable for liquidity management sits next to it: Aged Receivable and Aged Payable for the age of open items, and the Cash Flow Statement. For a real forward view you combine those with a budget you maintain yourself — this is how you build a budget with Odoo.

Calculating the ROI, without an invented percentage

The ROI of automation is not a benchmark you look up somewhere. It is a calculation in five steps, and you have every input in house.

1. Count the volume. How many purchase invoices, expense claims and bank transactions do you process per month? Do not estimate — count them in your current package. Automation pays off on repetition, and repetition is a number.

2. Measure the time, for one week. Have whoever does the posting keep track for a week of how long a purchase invoice takes. Split that time in three: retyping, checking, investigating.

3. Deduct only the retyping. This is the step most business cases get wrong. Recognition replaces typing, not checking. The documentation even prescribes that check: you correct the recognised fields and only then click Confirm. So calculate with zero minutes of typing and the same checking time as today.

4. Put the costs alongside. Document recognition is an In-App Purchase on prepaid credits: one document costs one credit. Enterprise customers with a valid subscription receive free credits to test the feature. XML documents through Peppol cost no credit. Add the one-off configuration to that, divided by twelve months.

5. Divide the outcome. Hours saved times your real hourly rate, minus credits, minus configuration per month. What is left is your figure — not ours.

Worked example: fill in your own column

Line	Your figure	Example
Purchase invoices per month	...	300
Of which already through Peppol/XML	...	90
Time per invoice today	...	4 min
Of which pure retyping	...	2.5 min
Time saved per month	...	12.5 hours
Hourly rate, administration	...	your rate
Credits per month (300 - 90)	...	210

The right-hand column is a worked example, not a benchmark. Fill in the middle column; only that one counts.

One effect you deliberately leave out of the sum: less retyping means fewer typing errors, and fewer typing errors means fewer corrections on your btw-aangifte, the Dutch VAT return. That effect is real, but we cannot capture it reliably in a figure — so we do not put it in the calculation and treat it as a bonus.

Rule of thumb for the question of what to automate: a task that comes back more than twenty times a month and takes less than two minutes each time is automation material. A task that costs three hours once a month rarely is.

What AI does not do — and why the responsibility stays with you

This part is missing from most articles on the subject, and it is precisely this part that determines your risk.

AI does not decide. The assistant in Odoo 19 can open views and show reports, but according to the documentation it cannot change data in the database. It advises; it does not post.

AI does not confirm. Document recognition fills in fields and puts the document ready as a draft. The action that counts — Confirm — stays a human click. Anyone who automates that click with Auto-post bills moves the check forward (the three faultless invoices) but does not abolish it.

AI does not sign. Your btw-aangifte with the Belastingdienst, the Dutch tax administration, stays your return. A wrongly recognised btw rate produces a wrong return, and the director is liable for that — not the software vendor. It is exactly this kind of configuration error that becomes expensive: see for instance the common btw mistake in Odoo on services outside the EU.

What Odoo does put up against that is evidence. The Audit Trail report records which changes affected the accounts: the date and time, the user, the type of change, the old value and the new value. With the Restrictive Audit Trail option, tracked records can no longer be deleted, only cancelled or archived.

So automation does not increase your risk — provided you set the control up explicitly instead of letting it quietly evaporate.

Frequently asked questions