AI or a Plain Rule? How to Diagnose Where Automation Actually Pays

The short answer: a rule inside the system you already run is enough whenever you can write the decision as one sentence that holds in every case — “every purchase request above fifty thousand goes to the finance manager”. You need AI when the input itself is unstructured: human text, a photograph of an invoice, a contract worded differently every time, so that no amount of added conditions will ever cover the cases. That is the only practical dividing line a business owner needs. Everything else is technical detail that will not change your decision.

The wrong question most people start with

The question usually reaches us as “how do we bring AI into the company?” It starts from the tool rather than the problem, which is why it has no answer. The answerable question is: “which repeated work consumes more of my team's time than it is worth?” — and only then do we ask whether a rule or a model is the right instrument for that specific work.

The order is not a rhetorical nicety. Start from the tool and you buy something, then look for somewhere to put it, and end up with spend and no effect. Start from the process and you have a clear standard of success before you pay anything. That is the principle behind BDC's AI and process automation service: we start from the problem, not the technology.

The practical difference: a rule knows the answer, a model estimates it

A rule is a fixed line of logic: if the condition holds, take the action. Its output is certain, auditable, and identical every time. If it is wrong, the error is visible and fixed by changing the condition.

A model is something else: it gives you an estimate with a probability attached. It reads an invoice and pulls the amount with high confidence, then gets it wrong on a badly printed one. That is not a defect — it is the nature of the thing. The real mistake is using it where estimation does not belong in the first place.

Hence the governing rule: never put a model where a rule can settle the matter. If the decision can be written as a condition, the rule is cheaper, faster, more accurate, and needs no human review. AI adds nothing here except cost and a layer of opacity.

A four-question test before you pay for any automation

These are the questions we actually work through in a diagnosis, and you can work through them yourself before speaking to any vendor:

• Is the input structured or not? If it is a field in your system — an amount, a date, a category, a status — it is structured, and a rule is enough. If it is an image, free text, or a customer message, a rule will fail.
• Can I write the condition as one sentence that is always true? If you hesitate and say “mostly”, you are looking at a judgement case, not a condition.
• How often does the task recur each month? A task that happens five times a month does not deserve a project, however irritating it feels. It is the task repeated hundreds of times that turns saving into a number you can see.
• What does a single error cost me? If an error means a wrong accounting entry or a contractual commitment, the output needs human review whatever produced it — and the cost of that review belongs inside your return calculation, not outside it.

If those four questions leave you with a structured input and a writable condition, you have just saved yourself an entire project. That rule can be built inside your system in a working day.

Where a rule is enough — examples from inside an ERP

People buy “intelligent solutions” for the following all the time. They are configuration, not intelligence:

• Approval routing: sending a request by amount, department, or expense type. That is a condition, not a judgement.
• Stock alerts and reordering: when an item drops below a threshold, a purchase request is raised automatically. The number is already in the system and the decision is arithmetic.
• Expiry and due-date alerts: overdue invoices, contracts approaching renewal, items nearing expiry. All of them are stored dates.
• Recurring reports: a report that goes out every Monday morning to whoever needs it. Scheduling, not intelligence.

When we find that everything an organisation needs is of this kind, we say so plainly: you do not need AI, you need your system configured properly. This usually surfaces early in ERP diagnosis and delivery, where what looked like a need for new technology turns out to be a process nobody has defined yet.

Where AI genuinely earns its place

There remains a kind of work rules cannot handle, because the input itself is unstructured. Three kinds of it are what we build:

1. Reading documents into records

A supplier invoice arrives in a different layout from every supplier. A contract carries legal wording that follows no fixed template. A rule cannot read them, so an employee reads them and re-keys the data by hand. Here extraction makes sense: the document is read, the fields are pulled, and the record is created inside the system. With one important caveat — the output stays a draft that needs human approval before it is posted, and that is not a weakness in the design, it is the design.

2. Classifying unstructured input

Categorising an expense from its free-text description, routing a customer message to the right department, ordering support requests by urgency. These are decisions a person used to make by reading text, and text does not reduce to a finite set of conditions.

3. An assistant that answers from company data

A question like “what are the payment terms with this customer?” has its answer sitting in a contract or a record, but reaching it means knowing where to look. An assistant that answers from the company's own sources removes the search. The essential condition here is that it is confined to defined sources and cites them, rather than composing a plausible general answer.

Those three are precisely what we build inside Odoo and ERPNext. Each one, and its limits, is set out on the AI and automation service page, including the cases where we will tell you not to.

The third case: a rule first, a model on top

The most successful designs are not “rule or model” but an order between them. The model reads the document and extracts the fields; the rule takes over from there. Above a certain amount it goes to human review. A new supplier is held until approved. Low extraction confidence is escalated to a person.

The point is that the model handles what a rule cannot — reading — while the rule handles what should never be left to estimation: authority and the final call. Anyone selling you an “intelligent system” that makes financial decisions on its own is selling you risk, not efficiency.

A worked example: the supplier invoice cycle

Take one process every finance manager knows, and break it into steps to see where each thing belongs:

• The invoice arrives by email: received and filed automatically. Neither rule nor model — just an integration.
• Reading the invoice number, date, amount, and line items: this, and only this, is where AI starts, because every supplier sends a different layout.
• Matching the invoice to the purchase order and goods receipt: pure rule. The numbers are already there and the match is arithmetic.
• Routing approval by amount and department: rule.
• Holding the invoice for review if the supplier is new or the variance exceeds tolerance: rule.
• Posting and scheduling payment: rule, after human approval.

One step out of six needs AI. The other five are configuration inside the system. Yet the whole cycle is sometimes sold as “intelligent accounts payable automation”. Once you break a process into its steps, it becomes hard to sell you what you do not need — and you become able to judge any proposal yourself.

The condition nobody puts in the proposal: the state of your data

Any automation, rule or model, runs on top of your data. If the same supplier exists under three names, items are duplicated, and the chart of accounts has not been reviewed in years, automation will move that mess faster. The model may extract the supplier name perfectly and still attach it to the wrong record, because the records themselves are not in order.

Which is why tidying data comes before any conversation about AI. It is unglamorous work — merging duplicates, standardising names, making fields mandatory — but it sets the ceiling on what can be automated at all. Anyone promising you AI without asking about the state of your data has not opened your system yet.

The price of a wrong diagnosis

Diagnosis goes wrong in two directions, and both are expensive.

The first: buying AI for a rule-shaped problem. You pay for something that could have been configured in your system, you add a layer that needs monitoring, and you end up with a decision you cannot explain to your auditor.

The second is quieter and probably costlier: leaving repeated human work exactly as it is because nobody ever counted it. Twenty minutes a day re-keying data appears in no report, but it appears in the delays, in the errors, and in the fact that your team spends its time transcribing instead of reviewing.

Diagnosis is what prevents both. That is why we place the automation review inside digital transformation consulting rather than treating it as a separate technical project: deciding which process to automate is a decision about priorities, not about tools.

How you know the automation worked

Before you build anything, write down one number you will measure afterwards. Not three, not ten — one. Valid examples: minutes to process a single invoice, days to approve a purchase request, records entered by hand per week.

And measure it before you start. Automation with no “before” reading cannot be proved to have succeeded, and months later the discussion becomes a contest of impressions. Then watch a second number alongside it: the share of cases that needed human intervention. If it stays high, the diagnosis was wrong, and the right response is to revisit it rather than defend it.

What we have built ourselves

We would rather be plain about this: our AI capability rests on what we have built for ourselves, not on a client list we can parade. The clearest example is Raqeem, our Arabic AI learning platform — a product we build, run, and carry the consequences of, not a slide.

On automation inside business systems, the experience comes from a decade of Odoo and ERPNext delivery: approval routing, integrations between systems, and cutting manual entry. That is the foundation any AI layer sits on — and building the layer on top of an undisciplined system multiplies the mess rather than clearing it.

In summary

AI is not a stage your organisation graduates to. It is a tool suited to one specific kind of work: unstructured input. Everything else — and in most companies that is the majority — is settled by a rule inside your existing system, at lower cost and with far more clarity.

Start with one process whose number you know, and diagnose first: structured input or not? A writable condition or a judgement? The answers to those two questions decide the tool, and save you an entire project pointed the wrong way.