Most people who come to us asking for AI want automation. Not everyone, and not always. But often enough that it is the first thing we check, and often enough that checking it is worth more to a client than anything else we do in the first week.
This is a firm arguing itself out of the bigger invoice. That is a fair thing to notice, and I would rather deal with it now than pretend it is not there. The reason we do it anyway is at the bottom.
What actually separates the two
Automation carries out a decision you have already made. AI makes a decision you have not.
If you can write the rule down, it is automation. When an invoice arrives from a supplier on this list, pull out the total, match it against the purchase order, and flag anything more than the agreed variance. Every branch in that sentence is knowable in advance. You are encoding something you already understand, and the encoding is cheap to build, cheap to test, and loud when it breaks.
AI is for the cases where you cannot list the branches. A photograph of a damaged pallet. An email that might be a complaint, might be a reorder, might be both and also mention a change of address. Handwriting on a delivery note that three different drivers fill in three different ways. The input varies in ways nobody can enumerate ahead of time, so a rule will not reach; you need something that generalises from examples instead.
Most of the work companies want done is the first kind wearing the second kind's clothes.
Three questions that settle it
You can run this yourself, before you talk to anyone who sells either.
Can you write the rule down? Not the summary, the rule. If you sat with the person who does the job today and asked them to narrate every decision for an hour, would you end up with something a careful colleague could follow? If yes, you want automation. The hour is worth spending regardless, because it is the same hour that tells you whether the process is worth keeping.
Does the same input always deserve the same answer? Rules are consistent by construction. Models are consistent most of the time, which is a different property and a worse one when the answer needs to be defensible. Payroll, compliance thresholds, anything a regulator might ask you to explain later: consistency is not a nice-to-have there, and a model that is right nearly always is the wrong shape of tool.
What does being wrong cost? This is the one people skip. A rule that breaks stops and shouts. A model that is wrong keeps going, fluently, and produces something that looks exactly like the correct answer. If a mistake is expensive and hard to spot, you want the thing that fails loudly.
Three yes answers and you are looking at a workflow, not a model. That is usually a smaller build, a shorter timeline and a system your team can reason about without us in the room.
The objection that has weight
Automation is brittle. This is true and it is the strongest argument against everything above.
A rule written for the invoices you get today breaks when a supplier changes their layout, when someone adds a column, when the finance team starts using a new field for something it was never meant for. The rule does not adapt. Somebody has to go and change it, and if nobody does, it quietly stops covering the cases it used to.
A model degrades more gracefully. It will often still be roughly right when the input shifts, which for some jobs is worth more than being exactly right on the old shape of input.
So the honest version of our position is narrower than the slogan. Automation is the better answer when the process is stable enough that the rule will still be true next year, and when someone owns it. If the process changes every quarter and nobody is responsible for it, a rule is a maintenance liability and you should account for that before you build one.
That is a question about your organisation, not about the technology. It is also the part of the conversation that usually turns out to matter most, which is why the assessment starts there rather than with tooling.
Where a model genuinely earns its place
Reading things that were written by humans for humans. Sorting a pile of unstructured input into categories nobody wrote down. Extracting the same six fields from a document that arrives in forty different formats. Drafting a first version of something a person will edit anyway.
Notice the shape those share. The model handles the messy, ambiguous edge, and a rule or a person handles the decision that follows. That combination is most of the good work we do. It is much less common for a model to be the whole system than the current sales pitch suggests.
What to do differently
When you next write down what you want, describe the job rather than the technology. "We want AI for our customer service" is a solution looking for a problem. "Most of the email our support inbox gets is asking where an order is, and the answer is already sitting in our system" is a problem, and it very nearly solves itself once written down that way.
Then ask whoever you are talking to which of the two they think it needs, and why. If the answer arrives before the questions do, you have learned something useful about them.
As for the money we talk ourselves out of: a system that gets abandoned is worth nothing to us. We would rather build the smaller thing that is still running in two years, because that is the client who calls again and the work we can point at. What we have built is mostly the unglamorous version of what was originally asked for, and that is not an accident.