What changes

Reporting has always worked the same way. Someone designs a report. You run it. If you want a different cut, you ask for a new report and wait.

The change is that you can now ask — in plain language — and get an answer from your live data.

“Which customers grew the most this year.” “What did we sell in the north region last quarter compared to the one before.” “Which products have the worst margin.”

No report to commission, no waiting.

That is genuinely useful for the one-off questions that were never worth building a report for. It also introduces a problem that a designed report does not have.

The problem

With a report you built, you know how the number was calculated. You know which records are included, which are excluded, and what “revenue” means in that context.

With an asked question, you may not.

Does “revenue” mean invoiced, ordered or delivered? Does “this year” mean calendar or fiscal? Are cancelled orders excluded? Are intercompany transactions included?

The answer will be produced confidently either way.

Where it helps

Four situations, all genuine.

One-off questions. The thing you want to know once, that is not worth a report.

Exploring before committing. Looking around your data to work out what you should be measuring, before designing something permanent.

Follow-ups. You saw something odd in a report and want to look one level deeper.

People who cannot build reports. Which in most companies is most people. Removing that dependency on one technical person is real value.

Where to be careful

Anything going to a board, a bank or an auditor. Use a defined report where you can explain the calculation.

Anything you will act on with money. Verify before you commit.

Comparisons over time. If the definition shifts between two questions, you are comparing different things without knowing it.

Anything regulatory. Statutory reporting needs a fixed, documented method.

A useful rule: ask freely, verify before acting, and use defined reports for anything you have to defend.

The bigger issue

Worth saying plainly, because it is not what most people worry about.

The risk is not that the AI computes wrongly. It is that your data is wrong and the answer looks authoritative.

If your product costs are out of date, a margin report is wrong — asked or designed. AI does not introduce the error. It makes it faster to reach and harder to question, because the answer arrives in a sentence rather than a spreadsheet you had to think about.

Four data problems that quietly corrupt reporting in most systems:

• Duplicate customers, splitting one relationship into three
• Wrong or missing product costs, making every margin figure fiction
• Inconsistent units of measure, making quantity comparisons meaningless
• Cancelled and draft records included or excluded inconsistently

Fix these before investing in reporting of any kind. They matter more than the tool.

Making it reliable

Five habits.

Agree your definitions once. Write down what revenue means, when a sale counts, what is excluded. Share it. Without this, two people asking the same question in different words get different answers and argue about which is right.

Verify anything important. Cross-check against a report you trust before acting.

Ask precisely. “Revenue from invoices posted between January and March, excluding intercompany” beats “how did we do in Q1”.

Promote what you ask repeatedly. If you ask the same question every month, build it as a proper report with a fixed definition.

Keep one set of official numbers. Board reporting, statutory reporting and anything external come from defined reports, not from questions.

What good use looks like

Explore by asking, commit by report.

Use questions to find what matters. Once something matters enough to track, build it properly, with a definition you can point at.

That gives you the speed of asking and the reliability of a designed report, without confusing the two.

The advantage Odoo has

One database again.

A question about customers can reach their orders, their invoices, their payment behaviour, their deliveries and their support tickets — because it is all in one place.

A reporting tool sitting on top of several separate systems is answering from whatever was last synced across, and it cannot see relationships that span the systems it was not given.

For questions that cross functions — which customers are profitable after support costs, which products cause the most returns — that difference is the whole answer.

What it will not do

Tell you what to ask. The quality of the answer depends on the quality of the question, and knowing which question matters is the skill that does not get automated.

Fix a bad chart of accounts. If your accounts are structured so that nothing useful can be separated, no reporting tool helps.

Replace understanding your business. A number without context is not insight. Knowing that margin dropped is data. Knowing it dropped because you took a large low-margin order deliberately is understanding.

The short version

Asking questions of your data is genuinely useful for exploration and for the questions nobody would build a report for.

Fix your data first — duplicates, costs, units, definitions. That decides whether any of it is worth reading.

Explore by asking. Commit by report. And keep one set of official numbers with a method you can explain.