Every business already holds the information its managers need. It sits in the ERP. What is missing is not the data, it is the distance between a question and its answer.

On 19 August 2026 we spent forty-five minutes closing that distance in public. No solution slideshow, no edited screen recording. A database, a series of questions, and the answers as they arrived.

One point before anything else, the same one we made in the room. The demonstration ran on a trial instance created for the occasion, with entirely fictitious data and eight anomalies planted on purpose. No real data, ours or a client’s, was ever on screen.

Simple questions cost hours

“Which customers are more than ninety days overdue?” means an export, a pivot table, a check. You get the answer by the end of the day.

“Have all our deliveries actually been invoiced?” is rarely even asked. You find out during the audit.

“Do we have a duplicate supplier?” means comparing records by hand, and nobody has the time.

All three were answered in seconds during the session.

Four words are enough to follow along

The ERP is the safe. Invoices, customers, stock: that is where they live.

The API is a service door into that safe. It has nothing to do with AI. It has existed for as long as the software has, and it is already what lets your ERP talk to your bank or your payroll tool.

The API key is the badge that opens that door. Named, revocable, with an expiry date.

MCP, for Model Context Protocol, is the shared language. It is what lets the AI know which tools it has in front of it and how to use them.

The security point fits in one sentence, and it is the one worth keeping: the AI inherits exactly the rights of the user whose key it carries. A user with no access to accounting produces an AI that is blind to accounting. It comes through the same door you do, with the same badge, and it cannot bypass the rules the ERP already enforces.

Nothing is copied, nothing is uploaded. The database stays where it is.

What the connection actually involves

The setup shown live has three stages. We describe them here because the question came up several times, and because knowing what goes into the configuration is the first condition for deciding what you are willing to put there.

First, on the ERP side. You choose the user who will carry the connection. That choice is not administrative, it is structural: it determines everything the AI will be able to see.

The key itself is generated from that account, in five clicks:

1. Click your avatar, top right, then My Preferences.
2. Open the Security tab.
3. Under API Keys, click New API Key.
4. Name it after what it is for, pick the RPC scope, and set a validity period.
5. Copy the key straight away. It is shown once and never again.

Two details matter here. The scope prompt offers rpc and mcp, and it is rpc you want: that is the classic service door our connector speaks to, while mcp covers Odoo’s own internal AI features. And the validity period is capped: we recommend three months, which forces a periodic review rather than letting the connection live a life of its own.

Second, on the workstation. A single configuration file declares the connector. With Claude Desktop it is called claude_desktop_config.json and sits in the application’s support folder. Here is the shape of it, with placeholder values:

{
  "mcpServers": {
    "odoo": {
      "command": "/opt/homebrew/bin/uvx",
      "args": ["odoo-mcp"],
      "env": {
        "ODOO_URL": "https://your-instance.odoo.com",
        "ODOO_DB": "your_database_name",
        "ODOO_USERNAME": "[email protected]",
        "ODOO_PASSWORD": "your_api_key",
        "ODOO_API_KEY": "your_api_key",
        "ODOO_TRANSPORT": "json2",
        "ODOO_MCP_ENABLE_WRITES": "false",
        "ODOO_MCP_ALLOWED_SIDE_EFFECT_METHODS": ""
      }
    }
  }
}

Three lines deserve a comment. The key appears twice, in ODOO_PASSWORD as well as in ODOO_API_KEY. That is not a mistake: leave the password field empty and the connection fails without a clear message. And to be unambiguous, it is the API key that goes there, never the account password. The transport is set to json2, the interface of the current Odoo generation; an older version needs the other one. The URL and the database point at your own instance, which is the whole point: nothing is copied anywhere.

Third, the two settings that decide everything. ODOO_MCP_ENABLE_WRITES is set to false in the example above, and that is the setting we recommend to start with. ODOO_MCP_ALLOWED_SIDE_EFFECT_METHODS names the business actions the connector is allowed to trigger, one by one: posting an invoice, validating a delivery, confirming an order. Left empty, nothing at all can be triggered. Anything not listed is refused, deletion included. These two parameters are the safety framework described further down, and they are set before the first question, not after.

What the file does not contain is worth saying too: no data. It describes an access path and a set of permissions, nothing else.

The technical part of all this takes half a day on an existing database. It is the third stage that takes time, because it requires settling questions that are not technical: who carries the key, which modules it reaches, and what must remain impossible even when someone asks nicely.

What fifteen minutes of questions surfaced

The questions were asked in plain language, with no formula and no filter. Here is what came back.

The aged receivables balance. Out of 106.8 million CFA francs outstanding, 58.1 million were overdue, or 54 % of the customer book. The AI also spotted a credit note of 855,500 francs left unreconciled since May, buried in the account of an otherwise active customer.

Three VAT anomalies. Two invoices at 10 % instead of the standard 18 % rate, and a consulting service invoiced as exempt to a cement producer with no supporting exemption certificate. Uncollected: 1,050,000 francs. The third case is the awkward one, because sample-based testing will not find it.

Deliveries never invoiced. Three delivery notes shipped in July and August, worth 14,085,000 francs before tax, with no matching invoice. A textbook cut-off failure, and an expensive one.

A goods receipt with no supplier invoice. 5,280,000 francs of goods received in early August, to be accrued.

A double-payment risk. The same supplier reference present twice, at 13,027,200 francs each, on two separate records differing only in capitalisation. No automatic reconciliation catches this: to the machine, these are two different parties.

Two invoices left in draft, one dating back to March, representing 5,675,800 francs of revenue never posted.

Total: 39.1 million CFA francs at stake, across eight findings, in fifteen minutes.

The AI proposes, you sign

The question that always follows this demonstration: fine for reading, but what if it writes?

Three locks, in this order.

Writing is disabled by default. A single switch. While it is closed, the AI cannot modify anything, even when explicitly asked. That is the setting we recommend to start with.

An allow-list of actions. Even with writing enabled, only the actions named in the list are possible. Post an invoice, yes, if that has been decided. Delete, never.

Human validation. The AI prepares and displays the exact operation, the system checks its technical validity, a human confirms. Without that confirmation, nothing happens.

We showed this both ways, live. A request to delete an invoice: refused, with the correct alternative offered, a credit note. A draft invoice posting: prepared, displayed, checked in the ERP where nothing had moved, then approved with a single word.

In accounting you do not delete, you reverse. The technical guardrail is aligned with the professional rule.

Building a dashboard in one sentence

This is the part that drew the most questions, so here it is in detail.

The dashboard was not prepared in advance. It was requested during the session, from the data already explored, with this instruction:

Build me a management dashboard in HTML, in the kaikai colours, navy 0B357F and orange F96F12. It should contain: monthly revenue for 2025 and 2026, the aged receivables balance, the top five customers, the revenue split between services and equipment, and a box listing the anomalies detected with their amounts.

Three things make that instruction work, and you can reuse all three.

It names the blocks, one by one. “Build me a dashboard” produces a generic page. Listing the indicators produces the page you actually need.

It specifies the format and the visual identity. HTML makes the page immediately viewable and shareable. The colour codes avoid the default rendering, which looks like nothing your company owns.

It builds on context already established. The AI had just spent fifteen minutes inside that database. It knew where to look. A dashboard requested cold, as a first question, gives a distinctly poorer result.

But the demonstration does not stop at the first dashboard. We followed with:

Add a column with the average number of days overdue per customer, and sort from worst payer to best.

That is where the real shift lies. Not in the first dashboard, but in the fact that the second one costs fifteen seconds. The marginal cost of an indicator approaches zero, which changes how you steer a business: you can afford to throw a view away and rebuild it, instead of living for two years with a pivot table nobody opens any more.

Three things this does not do

Replace your judgement. The tool produces a lead, not a conclusion. Professional responsibility cannot be delegated.

Remove the need to check. Every result was cross-checked in the ERP, and we did it at every step during the session.

Install itself. The technical connection takes half a day. Deciding who is allowed to do what takes the rest, and that is a management conversation, not an IT one.

The real risk is not the wrong entry. It is the wrong conclusion drawn from a correct reading.

What if you are not on Odoo

This was the most frequent question, before and after the session.

Odoo was the setting, not the promise. We are not an authorised Odoo partner and we sell no licences, which leaves us free to tell you when it is not the right answer. Depending on your processes, that answer may be Odoo, another package, or simply making better use of the one you already run.

The principle transfers anywhere a documented service door exists. On SAP, the interfaces exist and are solid; the constraint is mainly organisational. On Sage 100 and SAARI, widely used across our region, it is possible but more demanding: the vendor exposes no web API and you have to go through its business components, which means bespoke work. We say so upfront, not afterwards.

In every case the starting point is the same, and it is not technical: a diagnostic. Where your data sits, who reaches it, and what is costing you hours every month.

Where to start

We run a one-hour workshop on your own data, read-only, with nothing to install on your side. You leave with a list of your own anomalies, quantified, whether you go on to work with us or not.

For teams, kaikai Academy is 3FPT-accredited in the Information Systems domain, which opens your training programmes (AI, data, productivity, digital management) to possible funding, subject to your application being processed.

Support follows the same sequence you saw in the session: a diagnostic of your flows and your data, then connecting the tools with the rights and approvals that go with them, then the dashboards. We train your teams to run it before we leave, because a tool nobody owns does not survive six months.

Book a slot: calendar.app.google/RCeLhNZCPsY72Jvb7
Write to us: [email protected]

About the demonstration

The session was held live on 19 August 2026, on an Odoo trial instance created for the occasion. The dataset is fictitious and the eight anomalies were introduced deliberately, in order to show the detection work without exposing any real accounting data. All the figures quoted in this article come from that dataset.