Designing process automation in an ERP

Almost every ERP now ships with a workflow builder: drag the boxes, connect the arrows, watch the demo run. The question a serious buyer asks is not whether the engine can automate — they all can — but whether an automation you design in it will survive contact with a real month-end close. Most do not, and not because the engine is weak.

Automation is not a switch you flip; it is a design you write down. It fails when it is built for the case where every field is present and valid — the happy path — and then meets a reality where a payment arrives without a reference and a goods receipt posts after the invoice. This piece is about that design: the anatomy of a rule, when to reach for a deterministic rule rather than an AI proposal, where to keep a human on purpose, and what to automate first. Whether it paid off is measured separately.

Anatomy of a rule: event → condition → action

Every automation reduces to three named parts. The event wakes the rule. The condition decides whether it should act. The action is what it does. The load-bearing word is named: if you cannot name each of the three, you can neither audit the rule nor reverse its result. An engine that lets any of the three be arbitrary code looks more powerful in the demo and turns out more expensive in production.

The event

An event is a named change of state: a document arrived, a status changed, a threshold was crossed, a date was reached. That is not the same as a job that scans everything each night looking for changes. A batch over the whole register can do the work, but it cannot say why it touched that particular record — and without that answer there is no per-record audit and no per-record reversal. A rule bound to an event knows its cause; a nightly scanner knows only its clock. A single document raises several events across its life — received, matched, approved, paid — and a rule binds to exactly one of them; binding to the wrong event is why a rule fires too early, over data that is not ready yet.

The condition

The condition decides whether the rule may act, and it has to be deterministic and inspectable — anyone reading it should know in advance what it will return. The common trap is a condition that depends on data not yet present: the rule tries to match an invoice to a goods receipt before the receipt is posted. A well-designed condition can say not yet and wait for the next event, rather than fail — or worse, succeed wrongly on incomplete data.

The action: named, not arbitrary

The action must come from a closed vocabulary of named operations, each reversible and each leaving a trail. An engine that lets the action be run this script has neither a reverse nor an audit trail: when such a rule goes wrong, you know neither what it did nor how to undo it. A named action is exactly what lets you answer the two questions every rule must withstand — what did it do, and how is it reversed. And reversing is not a silent write-back of the old value but a recorded compensating action: the reversal sits in the journal beside the original, linked to the rule that produced it, because history you can quietly rewrite is not an audit trail.

• Draft a posting — the rule proposes the entries; nothing is posted without confirmation.
• Close a statement line — deterministic matching on a valid model 97 reference with a check digit.
• Raise a task — the work is assigned to a person, with a reason and a deadline.
• Block with a reason — the action stops and the why is recorded, so the block can be justified or lifted.
• Set a field with provenance — the value is written together with who wrote it, so automatic and manual entry stay distinguishable.
• Send a document — an e-invoice to SEF, for example, with the outcome of the send recorded.

Deterministic rule versus AI proposal

These are two different tools, and confusing them is the most common design error. A deterministic rule maps input to output by a rule you wrote yourself: the same input always yields the same output, and that can be proven. An AI proposal appears where the mapping is genuinely ambiguous — unstructured input, judgment, context you cannot capture as a condition — and its output is always a draft, never a finished action. The rule of thumb is simple: if you can write the condition, write the rule. Reach for AI only where the ambiguity is real, not where you would rather not write the condition. A utility invoice from the same supplier posting to the same account month after month is a deterministic rule — you write the condition once. A scanned delivery note with a quantity added by hand is AI territory, because the rule that would cover it cannot be written in advance.

Maker-checker as a fuse, not a formality

Automation removes the human from the loop by design; maker-checker is where you deliberately put one back. Not on everything — that cancels the automation — but on the actions where the cost of a wrong automatic result exceeds the cost of a single confirmation. It is a decision per action, with defined conditions under which the fuse trips: an amount over a threshold, a new counterparty, a low-confidence proposal, the first time a rule fires for a tenant. What matters is that the person confirming sees the proposed action and the evidence behind it, not a context-free yes/no button. Who may approve, and up to what limit, is a separate authorization question handled by another layer. A fuse nobody looks at is decoration: if the person confirming approves everything in turn without reading, the control exists on paper and not in practice. So the share of confirmations passed with no edit at all is tracked as a signal — the threshold may be set too tight, or the review has become a rubber stamp.

What to automate first

The selection criterion has two axes: frequency and ambiguity. High frequency justifies the cost of the design — a rule that fires twice a year never returns the investment. Low ambiguity means the condition can be written deterministically and the rule will not spend its life in exceptions. Only the intersection of the two axes says where to start, and it separates a candidate worth automating from one that will cost you a year of maintenance.

Traps of low-code engines that never pass the test

A workflow builder always works in the demo, because the demo runs the happy path. What separates a demo from production is not how rich the engine is, but how a rule behaves when something goes wrong — and in production something always does. These are the mistakes that recur regardless of which engine sits underneath:

1. The happy path only. The rule is designed for the case where every field is present and valid; the first partial payment or invoice without a purchase order breaks it.
2. No idempotency. The rule fires twice on a retry — a network blip, a message-queue redelivery — and creates two postings instead of one. The same event processed twice must produce one result, or the engine is a duplicate generator.
3. Silent failure with no dead-letter queue. When the rule cannot complete, where does the work go? If it vanishes without a trace, this is not automation but a data-loss machine; there must be a queue the failed event lands in and waits.
4. A hard-coded parameter in the condition. A rate or threshold written as a literal in the rule: the law changes and the rule keeps firing on the old value, because the parameter has no time validity separate from the code.
5. No rule versioning. You change the condition and can no longer tell which version produced last month's postings — the first question an auditor asks.
6. The run-a-script escape hatch. An engine that lets the action be arbitrary code turns supervised automation into unauditable work with no trail and no reverse.

How NG One approaches it

NG One models automation as named rules over an event stream. Every action comes from a closed vocabulary, writes provenance and can be reversed; AI produces drafts only; maker-checker is a per-action fuse configured by tenant, process and threshold. The Automation Center, in the Insights, automation and AI space, shows active rules, the conditions under which they stop, and their execution history. In the demo tenant, for instance, one rule closes statement lines on a model 97 reference and sends the remainder to a resolution queue, while a recurring-utility-invoice rule drafts a posting that a person confirms. These are configurations for display, not measured outcomes at a named customer. The same rules and their results also surface on the home screen, in the user's own terms — how many statement lines closed on their own, how many drafts wait for confirmation — and each such figure drills through to the records behind it; a number with no path back to the records is a slogan, not an insight.