360 AI OCR

1Why

Odoo's OCR was not built privacy first, and clients are starting to ask about it. Here is what they find.

Odoo's OCR keeps the bill for 6 months and uses it to improve their product. Their own IAP policy: "stored on our server for a duration of 6 months", kept "to be used in the continual improvement of our service."

And it sends the accounting data back. On every posted bill, _validate_ocr returns the corrected values to Odoo. Totals, dates, invoice number, partner, VAT, IBAN, and every line's description, quantity, price and tax. Not the scan. The accountant-approved version. A client's auditor can read that in the source.

Nobody opted in. account_invoice_extract is auto_install: True, and vendor bills default to auto_send. 92 of our client databases have it, and none of them chose it.

To be fair to Odoo: processing stays in the EU, they are a processor under a DPA, and no rule is being broken. But clients would rather hear this from us than from their auditor.

2What we sell

Odoo does have an opt-out. It is called turning the feature off. What they do not offer is using the OCR without feeding it. Say that first, before someone else does.

Cost. Odoo is €0.15 to €0.05 per document by pack size. Textract is $0.01 per page, Haiku about €0.006 per bill. No blended figure until Phase 2 measures how many bills need the AI. Do not lead with cost anyway. At our volumes it is a few hundred euros a year.

3How it works

1. OCR. Textract AnalyzeExpense in an EU region, inline bytes, nothing written to S3. Returns fields with confidence scores plus a box for every word.

2. Reconciliation. Arithmetic, no AI, free. Subtotal plus tax against total. Lines against subtotal. Confidence floor. Ambiguous dates.

3. AI, only if that fails. Claude gets the page and Textract's candidates, and picks between them. Most bills never reach it.

Result goes into Odoo's own _fill_document_with_results(). Partner matching, tax matching, bank accounts, payment terms all keep working. We rebuild none of it.

Where we hook in

Override _contact_iap_extract(), not _upload_to_extract(). It is the documented override point and the only place the mixin talks outward. Three verbs:

• parse returns a token
• get_result returns our ocr_results
• validate does nothing, which is what stops the data going back to Odoo

We then inherit Odoo's state machine, banners, crons, webhook, batching, correction widget and test mocking. All unchanged, none of it ours to maintain.

Rule: three verbs, nothing else in that mixin.

4Getting better without keeping data

Odoo improves because every correction across their whole customer base feeds back. We keep nothing. So how do we ever catch up?

You do not need the invoice to learn from it. You need to know that for this vendor the total sits right of "Te betalen" and dates are day first. That is a fact about a vendor's template, not about our client's business. The same template goes to hundreds of companies.

So we store rules, never values.

Matching a rule to a bill. Key on the VAT number, or the IBAN. Both checksum offline, so a misread digit fails the check and we simply do not match. Names are useless as keys.

No chicken-and-egg problem. Finding a VAT number is a content match that works on any layout we have never seen, so rules are never needed to identify the vendor. They only refine the rest.

The gate keeps it safe. If the bill reconciles, rules are never touched. If not, apply the rule and reconcile again. Still wrong means the vendor redesigned their invoice, so the rule gets demoted. A stale rule cannot corrupt a good read, because the arithmetic has to agree first.

Two tiers.

1. Telemetry. Log why the gate fired. "date ambiguous", "line sums mismatch". No text, no amounts, no vendor. Tells us where the parser is weak without anyone seeing a bill.
2. Remember what worked. When a bill reconciles cleanly, store the geometry that worked. No user signal needed, so no patching Odoo's JavaScript, and nothing stored that could be client data.

We also do not fine-tune on client documents. That needs the corpus we promised not to keep.

5Plan

Phase 0 is four things, and only one is engineering.

Tell the clients. A short neutral advisory, no product pitch. The fix is free and available today, and the question is already being asked. Walking in three months later with something to sell, having said nothing, is the one version where we look bad.

Audit. How many companies actually run something other than no_send, and how many bills carry a non-default extract_state. Its own job across 92 databases.

Design partners. There are clients who would want to share in the development. Two of them would fund a good part of this, and give us the real scanned bills Phase 6 needs. Consent has a lead time, so start now.

AWS. See below.

Two more Phase 0 answers needed before Phase 1. Who owns the AWS account. And can synchronous Textract take a 30-page bill, because if multi-page forces the async API, that needs S3, and S3 breaks the retention story.

6Risks

• Word boxes will break on upgrade. Odoo rewrote that whole surface between v18 and v19 with no migration. Isolate the mapping in one function behind a test and budget a day per major version.
• Accuracy on real Dutch bills is unmeasured. Phase 6. The engine is pluggable if Textract disappoints.
• Per-line tax rates. Textract never gives them. Get it wrong on a mixed 9% and 21% bill and the wrong tax lands in the ledger and still reconciles. Hence its own phase.
• Sovereignty. We pitch "more private than Odoo" while moving data to a US hyperscaler. EU region plus SCCs is a real answer, but someone will raise the CLOUD Act and we need one ready.
• Liability moves to us. Odoo carries it today. Under our design 360 becomes the processor for 92 clients' payables. Question for Kees on insurance and SLA.
• The Odoo processor argument needs a lawyer, not us. It is sharper than the retention point and worth a real opinion.