Rule or AI model: how to decide for each step of a task

The question is too big. An office task such as paying a supplier bill is not one decision. It is a chain of small steps, and each step has its own nature, its own inputs and its own cost of being wrong.

Write the chain on paper first. Include the trigger, each check against the purchase order, each lookup in the vendor master and each handover to an approver. Nothing should hide inside a vague box called processing. Then test every step on its own. The answer will differ along the chain.

Teams that skip this step end up buying a model for a job where a spreadsheet formula would do. Others hand-code regular expressions for a step where every supplier formats the bill differently, and then spend each month patching them. A returns desk shows the pattern. The barcode scan, the RMA number lookup and the refund limit check are rules. The customer’s typed reason, with its typos and slang, is the only part needing a model.

A step suits a rule when you can state the condition in one sentence and the same input always gives the same result. Payment received means mark the invoice paid. Stock below reorder level means raise a purchase request. Simple.

Rules are cheap and fast. When one misfires you can read it and see why, because the logic sits in plain view. An auditor can follow it too, which matters for approvals, credit limits and any step that touches tax or bank details.

If you keep adding exceptions to a rule, pause. Ten exceptions often mean the input is messier than you thought, and the step belongs with a model instead.

A step suits a model when a person reads something and makes a judgement, which is the one thing a rule cannot copy. A supplier bill arrives as a scanned PDF, a phone photo or an email body, and the total sits somewhere different each time. Extracting it is reading. It is not arithmetic.

The same goes for sorting an enquiry into sales or support, spotting the tone of a complaint, or drafting a first reply. Customers write three paragraphs and no question. Wording varies too much.

Models are sometimes wrong. So give each model step a confidence score. Send anything below your threshold to a review lane, where a clerk corrects the field before the flow carries on.

Take the supplier bill again. A model reads the PDF and returns supplier, bill number, date and amount. A rule checks that the supplier exists in the vendor master. Another rule runs a three way match of the bill against the purchase order and the goods receipt note, flagging any mismatch beyond a set tolerance.

A final rule routes it. Matched bills go to the approver and mismatches go to a clerk. The model did one step out of six. The rest were rules, which is why the flow is cheap to run, quick to test and easy for an auditor to follow from start to finish.

Keep the model’s output as plain fields, such as a decimal for the amount and an ISO date. Downstream rules then stay testable without the model in the loop.

For each step, write down the worst wrong answer. A mislabelled enquiry costs a slow reply. A wrong bank account extracted from an invoice costs real money, so a human should always confirm that one field.

Run the flow beside the manual process for two weeks. Compare outputs line by line and log every disagreement in a sheet. Patterns appear fast.

Then give each step a status: automate fully, automate with review, or leave manual. Revisit the list after a month of real use, because suppliers change their templates without warning.