Three of our newer Business Central extensions — Direct Banking, SpendFlow and Planning Studio — all have an AI component that customers ask about first. The interesting part of the conversation is never what the AI does. It is what runs before it, and what happens after.
The pattern we settled on across all three is what we call Rules First, Claude Second, Human Accepts Everything. This post is about why.
The naive shape
A first-generation AI feature in an ERP looks like this: the user takes an action, the app sends the whole context to an LLM, the LLM returns a decision, the app applies the decision, the user finds out afterwards whether the decision was right. It ships fast because there is almost nothing to build. It also creates a specific kind of trust erosion that finance teams find intolerable: they no longer know what the system will do next.
The finance director we have talked to about this problem the most has a phrase for it: "if I cannot predict the next entry in the ledger, I cannot sign the ledger." She is right. Every AI feature in a system of record has to work with that constraint, or it gets turned off within a quarter.
The pattern
Rules First. Every match, categorisation and suggestion the system makes runs through a deterministic rule engine before it touches the AI. The rules are authored by the customer's finance team, priority-ordered, and every match they produce is auditable — the rule that matched, the fields it matched on, when it last changed.
In Direct Banking, that engine is SFD Reconciliation Rule. A rule can say "if the payee text contains ACME and the amount is within 0.5% of any open receivable from Customer ACME Ltd, match it." Rules are per-bank, per-priority. A well-authored rule set matches 70–90% of a typical daily statement without any AI involvement at all.
Claude Second. Only the residual — the lines the rules did not match — goes to the AI. And it goes with a tightly-scoped context: this bank line and the specific open receivables/payables that are plausible candidates. Not the entire ledger. Not customer master data. Not any dimension beyond the ones the match algorithm needs.
The AI returns a proposed match with a rationale — which field it matched on, why it thinks this candidate is right, what its confidence is. Every response is validated against the BC ledger schema before it is shown; a proposal that does not resolve to a real, open, unmatched entry is discarded silently. The user never sees an invalid suggestion.
Human Accepts Everything. Even a rule match with 0.999 confidence requires a click. There is no "auto-post" toggle. The reason is not that we do not trust the rule; it is that we want the reconciliation workspace to have exactly one Accept action, and for that action to always mean the same thing: a human just approved this. Auditors love it. Finance teams love it. And the eventual customer-side operator gets a system where every entry in the ledger has a name attached to the decision.
Why the order matters
There is a temptation to do this the other way — AI first, rules as a fallback for when AI is not confident. It sounds elegant. It is a mistake, for three reasons.
First, cost. Every AI call is a cost. Running rules first on 90% of the volume and Claude on 10% means paying for 10% of the AI you would otherwise pay for. Over a busy month for a mid-market customer, this is a real number.
Second, latency. The rules run in the same tick as the statement import — milliseconds. Claude runs in seconds. If you route AI first, the whole workspace waits for the slow path even on the trivial matches. Users notice.
Third, explainability. A rule match tells the auditor "this matched because rule 34 said so, here is rule 34." An AI match tells them "this matched because a language model thought so, here is the rationale." The first sentence is auditable. The second sentence is not. When most of your matches are rule matches, most of your audit trail is auditable. When most are AI matches, most is not.
The pattern generalises: any time you have a deterministic path and an AI path for the same decision, run the deterministic one first.
How it shows up in the other two
SpendFlow's policy engine. Structured policy rules — "meals under ₹1,200 auto-approve" — run first. Only expenses that no structured rule cleanly resolved are sent to Claude for evaluation of the natural-language policies ("no alcohol on training trips"). Every AI verdict is logged; the approver still clicks Accept.
Planning Studio's scheduling copilot. The scheduler's finite-capacity engine calculates all the deterministic constraints — alt-machine availability, calendar/shift math, downstream impact. When a planner asks Claude to close a gap, Claude is given the engine's output as context and asked to propose specific moves. The moves land in the AI Suggestions page. Nothing is applied to the board until the planner clicks Accept. Every accepted move goes through the same apply path a manual drag would use — the AI is not a shortcut around the engine, it is an advisor to the human at the console.
What we learned
The customers who like AI features in their ERP are not the ones who wanted a co-pilot that acts. They are the ones who wanted a co-pilot that shows its work. Rules First, Claude Second, Human Accepts Everything is our best answer to that so far, and it is the same pattern in three different modules for a reason: it composes with finance's trust model, not against it.
The interesting thing is that we did not invent it. It is what a careful finance director does with an intern: give them the rulebook, let them try the routine cases, escalate the edge cases, sign off on every entry. We just described the intern differently.