n8n: €480 Instead of €80 Due to One Unit Error

A participant on the n8n forum analyzed a simple example.

The customer requests 12 units; in the catalog, the price is €40 per pack of

The model correctly extracted the SKU and quantity, but directly multiplying "quantity × price" produced €480. Calculated by packs, the invoice would have been €80.

The article's main point: the value of AI automation is determined by the validator between the model's response and the company's commitment to the customer.

The model itself does not guarantee calculation accuracy.

The post's author put together a small Python example using synthetic RFQ (request for quotation) lines.

For this request, the system returned the status `review: unit_mismatch` and a blank amount: it refused to calculate and passed the line to a human.

Nine local tests passed, including malformed prices, unknown SKUs, and two legitimate cases that the validator must allow through.

Extraction worked perfectly; the business logic after it failed.

The request looked routine, but the price in the email would have become a commitment by the company to the customer.

Teams usually spend most of their effort on extraction quality: the prompt, model selection, and reference examples. Meanwhile, business rules remain in the manager's head.

The manager knows what “piece” means for this product, whether the package is divisible, and whether an incomplete package can be sold, but these rules are not in the workflow.

As long as the manager was part of the process, the gap went unnoticed.

When a company removes the manager, every undocumented rule starts costing money.

Another author describes a similar principle in a thread about customer support.

Automated actions are allowed only through an API call allow-list, and anything involving money is first sent to an operator.

His triage pipeline works as follows: items are classified, the LLM drafts a response, a rule-based validator checks each draft, and one retry is made after a failure with the reason provided. The model proposes; the rules decide.

In one feed, three authors described the same architecture over the course of several days. Small, testable endpoints.

Database searches and API calls are isolated in separate tested functions, while n8n orchestrates the conversation.

The logic lives in code that can be tested, and the author does not create nodes with hidden copies of it. Explainable scores. In the description of a lead-generation system for around 5,000 contacts, fit is scored on a scale from 1 to 10, with the factors behind each score shown for every record.

A person can see why the record was flagged and correct the rule. Demo without access credentials.

The Google Calendar overlap report comes with a `demo_mode`.

Five fictional events turn into three busy time slots and one overlapping pair. You can import and test the workflow before connecting credentials.

The task follows the same rules: a booking made by phone or directly in the calendar bypasses the booking form, so the report looks specifically for what the form missed.

AI automation has two costs: the cost of building it and the cost of one undetected error.

An error in an RFQ costs the difference between €80 and €480.

Multiplied across a stream of requests, it results in a loss or a lost customer.

A budget for "AI in sales" is justified when the process has a safeguard.

Without it, the company gets a polished demo that does not improve the metric, or worse, drives it down—and the person who approved the budget is held responsible.

Candidates in the same threads describe themselves this way: "I build things that work, not presentations about what could work."

Customers assess a provider by a functioning workflow with checks and look at that before reviewing the technology list.

In KT.Team integration projects, the rule is that the model cannot write to the accounting system.

Between it and 1C, Bitrix, or Odoo is a validation layer that we build together with the process. -

Data extraction and business validation are separated.

Units of measurement, pack multiples, permitted ranges, and reference data are checked by Python or C# code that can be covered by tests. -

The agent's actions are limited to a list of permitted operations.

Through MCP, we expose only tools that are safe for automatic invocation to the agent.

Money-related operations are sent to an approval queue. -

Requests to models pass through the LLM & Security Gateway.

It records the log, limits, and data filtering, so any decision can be reconstructed. -

For catalog and policy-related answers, we use RAG, where the source of every statement is visible and verifiable. -

We build orchestration in n8n or Kafka so that any step can be disabled without stopping the others.

On the surface, the result looks simple: the request arrives, the price is calculated, and the questionable line is sent to a manager.

This simplicity is ensured by tests, reference data, and clearly defined responsibility shared between the model, code, and people.