SAP B1 blog

This is the fourth episode in a series on this blog that deals with AI fundamentals in combination with SAP Business One. Up to now, it has mainly been about what a language model learns before it is even used: human ratings, trial and error, and the step-by-step checking of intermediate results. This episode reverses the perspective. It is about what happens while a model is already working, using a tool or having code executed, and how it reacts to what actually comes out of it. Two methods are at the centre that sound more similar than they actually are: ReAct and RLEF.

Read more: ReAct und RLEF: Wie Künstliche Intelligenz aus echten Fehlern lernt — und was der automatische Bankabgleich in SAP Business One damit zu tun hat

.

Reacting is not the same as learning

An AI agent that notices an error and doesn't repeat it on the next attempt seems like common sense.

In fact, the exact same agent still repeats the mistake in the next session, and reliably so. The non-repetition only applies within a single ongoing task. As soon as the task is finished, the model knows just as little as before.

For a company considering AI-powered automation, this is not an academic detail. Invoice bots, coding assistants and support agents now almost all advertise with the same phrase: „The system learns from its mistakes.“ The phrase is almost always true, it just rarely means the same thing.

An example makes the difference tangible

A coding assistant that corrects a syntax error within a session appears capable of learning. If you open a new session the next day with a similar task, it makes the exact same mistake again. This is not a defect, but simply a different process from what is commonly understood by „the AI is learning“.

The question is therefore not purely a technical one. Anyone who introduces recurring automation, for instance for document verification or payment reconciliation, tacitly relies on the assumption that errors will become less frequent over time. Whether this actually happens depends precisely on which of the two procedures discussed here is operating in the background.

An example from SAP Business One is also provided here: a deterministic mechanism that sits right on that threshold between mere reaction and genuine learning. Where it actually stands on this threshold will be clarified further down.

A new employee with short-term memory loss

Imagine a new employee who is given an unfamiliar task and thinks out loud. He considers what needs to be done, tries a first step and looks at the result. After that, he aligns his next step accordingly. By the end of the working day, he has solved the task, with a few detours, but ultimately correctly.

The next morning, the same employee is given a similar task. He starts from scratch again. Not because he is clumsy, but because nobody explicitly taught him what he had painstakingly worked out the day before. Yesterday's initiative was real, it just left no trace.

It is precisely this pattern, in two different variations, that underpins the two approaches discussed in this text. One is akin to the employee’s day-to-day work: a model acts, observes and adjusts the next step, all within a single task. The other ensures that something of substance actually remains once the day is over.

Thinking, acting, observing, and what is left over afterwards

Both methods have been given their own names: ReAct and RLEF. Both revolve around the same basic building block: an action, a real-world result, a reaction to it. Exactly what this building block looks like in both cases differs significantly.

The ReAct loop

ReAct stands for „Reasoning and Acting“. The method integrates verbal thought processes with concrete actions, rather than treating the two separately. A model is given a task or question and works through it in a loop.

1. The model formulates a step in the thought process in text form, for example, what information is missing next.
2. From this step of thought, it derives a concrete action, such as a search query to an external source.
3. The action is carried out, and the result is returned to the prompt as an observation.
4. Based on this observation, the model formulates the next step of thought, and the loop begins again.
5. As soon as enough information is available, the model completes the task with the actual answer.

What is important is what does not happen within this loop: no training takes place. Every observation simply ends up as additional text in the current prompt. As soon as the task is complete, this text disappears again, and with it everything the model has learnt in the meantime.

The RLEF loop

RLEF stands for Reinforcement Learning from Execution Feedback. The method comes from software engineering and continuously improves a model's handling of code, rather than just within a single task.

1. The model receives a task description in natural language and generates an initial code draft.
2. The design is being run in a test environment against publicly available test cases.
3. If a test fails, the exact error message is fed back into the context, and the model generates a new draft.
4. A design that has passed the test also undergoes additional hidden, private test cases that were not visible during its creation.
5. The results of these private tests produce a simple ‘pass’ or ‘fail’ indication.
6. This signal is incorporated into an actual training step that modifies the model's parameters.

The decisive difference from the first method lies in this final step. Here, something actually changes in what the model is subsequently capable of, independently of the individual task it was just working on.

The one crucial difference

Both methods respond to a real-world outcome, an observation or a test result. Only one of the two actually uses this outcome to verify that a genuine learning step has taken place.

In ReAct, the observation remains part of the ongoing conversation, nothing more. In RLEF, the execution result becomes the verifier that decides on pass or fail, and this verdict changes the model itself via a parameter update. A model trained with RLEF brings this learned behaviour into every future task. A model working only with ReAct carries nothing forward from any completed task into the next one.

Bank reconciliation has long been based on this principle

Now let’s turn to the ERP system that most readers of this blog are actually interested in. SAP Business One processes bank statements automatically, and this involves a mechanism that is strikingly similar to what has just been described.

If, during the first reconciliation attempt, the system does not find enough open transactions that match an item on the account statement, it does not simply stop. It automatically initiates a second round with more lenient criteria, and if that is still insufficient, a third, even more lenient round. Up to three reconciliation rounds, each more lenient than the previous one, without the need for manual intervention. The result at the end of a successful round is a Booking suggestion, which can be checked once more before the booking is finalised.

Structurally, that is almost exactly the ReAct loop from just now: an attempt, a result, an adapted next attempt. The difference is the same as above. The three tolerance levels are hard-coded, today just as much as a year ago, regardless of how often round two or three was needed and how reliably they hit the mark in the end. The fact that such a checking mechanism is not automatically a learning system has already been demonstrated in this series using the example of the Approval process in SAP Business One shown. A ‘fail’ signal triggers the next step in both cases. However, no one assesses whether round two or three is more reliable in terms of timing than the previous attempt.

What if the cascade itself were to learn?

Here is a thought experiment. The extension described below is not currently included in SAP Business One, but is certainly conceivable with AI.

The three tolerance levels in the bank reconciliation cascade could learn from their own history, rather than remaining fixed for all time. A system that tracks which tolerance level actually led to a correct match and which led to an incorrect one for each type of discrepancy allows this experience to be incorporated into the next adjustment of the levels. Round two then no longer uses the same fixed limit for all amount discrepancies. It will be set more narrowly or more broadly, depending on what has so far proved reliable in similar cases.

This would give the cascade precisely what, according to the description above, it lacks today: a genuine learning step, similar to the parameter update in RLHF, but relating to its own tolerance limits rather than to an entire language model.

The catch lies in the data source. A system of this kind learns not only from carefully verified matches, but also from those instances where someone, under time pressure, has simply waved through an uncertain match. A single moment of carelessness does not simply result in a single entry, but becomes embedded in the setting of future tolerance levels, unnoticed, until someone deliberately checks the discrepancy.

Who it's worth it for

This article is aimed at managing directors and CFOs working with SAP Business One who want to assess whether a „learning“ AI tool actually continues to learn over time or merely reacts within the current session, before deciding how much trust to place in such automation.

Anyone who does not use SAP Business One can still take away the clarification of terms regarding ReAct and RLEF; the ERP reference is simply dropped. And anyone looking for a concrete buying recommendation for a coding assistant or an AI automation tool will not find it here: this text creates conceptual clarity, not a product decision.

Bank reconciliation in SAP Business One does not become any smarter through this comparison; its three tolerance levels remain what they are. But anyone who knows that „reacts to an error“ and „learns from an error“ are two different promises will listen more closely the next time an automation offer is made as to which of the two is actually being sold.