Where n8n is enough: rule-driven order intake into ERP

Most order-intake work follows stable catalog and unit rules. The design should identify the one place where interpretation helps and leave repeatable decisions to code.

A wholesale clerk retyping orders performs three kinds of work: recognizing SKUs, converting units and packaging, and telling a safe substitute from a case that needs a decision. The first two are rules. The third is judgment, and it should stay with a human.

The division of labor: n8n, code, human

In the order intake system we built, each of these three roles has the right executor.

n8n receives orders from email and files, routes them, retries failed steps, and prevents messages from being lost or handled twice. A durable queue with duplicate protection solves this part of the process without an agent.

SKU matching, unit conversions, and substitute assessment are deterministic rules in code, with a typed result. The same input yields the same decision, and the decision can be tested like any function. A model may read an untidy order into structured lines, but it does not decide what enters the ERP.

A line without confident catalog confirmation has no write path into the ERP. It creates an operator task showing the proposed SKU, rejected candidates, and the reason for each rejection, which keeps the decision brief and well-supported.

Where a model would add risk

An agent loop makes sense when a task requires repeated tool use and judgment at several steps. Here, judgment occurs in one place and belongs to a person. Silently posting an ambiguous line would surface at delivery and cause a return, a correction, and loss of customer trust.

Using a language model for those deterministic decisions would reduce predictability at the point where the process depends on repeatable rules. The appropriate design may therefore be a workflow with one narrow model step rather than an agent loop.

Split the workflow before choosing the technology

Trace one order line from the customer's message to the ERP record. For every step, decide whether the result comes from a stable rule, interpretation of language, or a commercial judgment.

This exercise usually places the model near the input, where customer language varies. The middle of the workflow stays deterministic, and a named operator owns the uncertain edge. An agent framework cannot compensate for missing unit mappings or an inconsistent catalog.

Failure modes that appear after launch

Catalog drift. A SKU is retired or its packaging changes during the day. Every decision should therefore retain the catalog version it used.

Duplicate intake. A customer resends a file or an employee forwards it to another inbox. Duplicate protection needs to cover the message, attachment, and customer order number.

A technically successful write with a business error. The ERP accepts the record even though one line has the wrong unit or an incomplete commercial field. An integration success response does not prove business completeness.

An exception queue with no service owner. The gate works, but nobody resolves held lines. A pilot should measure the age of the oldest case and time to operator decision alongside extraction quality.

The measurement

The rules test used 480 generated orders and 2,400 lines. Catalog matching was correct for all 12 untidy descriptions, and all 21 gate checks ended without an unsafe automatic write. Median rule-decision time was 0.001083 ms across 2,000 local repetitions. A separate small-model order read using gpt-5-mini consumed 602 units of model text, took 3.99 seconds, and cost about PLN 0.0027. Client catalog quality and full intake time still need measuring during implementation.

The lesson reaches beyond orders: determine whether the process needs a model before choosing an agent framework. A rule-based workflow may be the simpler and cheaper design.

The recorded measurements answer narrow questions: whether the prepared rules followed their specification and whether the gate stopped controlled unsafe writes. They do not establish the share of orders that will pass without operator help in a particular warehouse. That depends on catalog quality, customer habits, and the actual exception mix.

A pilot checklist for your own orders

Prepare these inputs before approving a rollout:

• orders from several customer groups, each with a manually confirmed expected result,
• the current product, unit, packaging, and substitute catalog,
• the ERP's required fields and the conditions that block an incomplete draft,
• a duplicate definition and a safe retry policy,
• an exception queue with a named owner and response target,
• separate measures for field extraction, SKU matching, blocked writes, and operator review time,
• a fallback to manual order entry when the integration or catalog is unavailable.

The useful pilot result is the share of lines completed correctly without correction, together with the time spent resolving the rest. Model-reading cost is one component of the operating cost, and often a small one.

Details are on the case page. A free process scan can separate the steps suited to fixed rules from those that genuinely require language interpretation.