SAP B1 blog

This is the first post in a new series on this blog. It looks at the possibilities of artificial intelligence in direct combination with SAP Business One. This is not intended to be a collection of product announcements. Rather, it is an attempt to think through fundamental AI topics at a leisurely pace. Reinforcement learning, reward models, verification, agents, whatever else is currently haunting conference presentations: each episode will tackle one of these terms and end with the same question — what of it actually makes it into everyday ERP life, and what remains vocabulary that sells well. We kick things off with a term that is currently being used particularly often: RLHF.

Read more: RLHF und Reward-Modelle: Was hinter dem KI-Hype steckt — und was der Genehmigungsprozess in SAP Business One damit zu tun hat

The lowered hurdle — and what it changes about thinking

You might think that a new process idea in the SME sector fails primarily because of a lack of ingenuity — that there is simply a shortage of good ideas about what could be done differently. In reality, it usually fails much earlier, namely at the silent preliminary calculation of what the implementation would cost — even before anyone has thought the idea through to the end. It is precisely this preliminary calculation that is currently shifting.

The hurdle that used to stand between a process idea and its implementation has become lower thanks to artificial intelligence. What was until recently a fundamental decision involving consultancy days, functional specifications and a long lead time can now be tackled more quickly and with less effort. Some things that were recently simply out of the question because it would have been too much effort even to try them have now become feasible.

The obvious conclusion would be to buy more software now. The more obvious conclusion is a different one: to think differently. Anyone who no longer has to think about the hurdle of implementation as a first step can think in terms of their own processes rather than in terms of what is supposedly feasible. The question shifts from „What can we afford to build?“ to „What would actually help us?“ and „What of that is NOT possible with artificial intelligence?“ — and that is no small shift.

Artificial intelligence helps to rethink processes

The real model for the future therefore lies not in the technology itself, but before it. Clarity about one's own processes, demands and wishes is essential. Anyone who knows where the daily business is snagging, which decision is repeatedly made manually, which information is never where it is needed, has already done half the job. This applies regardless of what is ultimately implemented as a result. And it is precisely this process of gaining clarity that can be thought through well together with an artificial intelligence, and not just the subsequent implementation. A conversation in which one puts one's own dissatisfaction with a process into words and receives follow-up questions in the process often sharpens the idea faster than any requirements specification.

What this means in concrete terms is shown later in this text using a single example from SAP Business One: a feature that has quietly been doing its job there for some time and, upon closer inspection, can be described in the exact same terms as what was just said about reflecting on one's own processes. Today, it is worth playing through such thoughts anyway—if only because the distance between idea and testing has become smaller.

One monkey, many trials, one examiner who selects

The expectation is well known: these days, an AI model simply types out the right answer, ready for publication and at the first attempt. That at least is how it sounds in a number of consultancy offers currently landing in SMEs„ inboxes with the addition of “AI-powered".

Actually, it usually works the other way around. Under the name „Large Language Monkeys Project“(all seriousness, no irony) a study has become known that proves what the infinite monkey theorem claims. Basically, it states: if you let enough monkeys bash away on a typewriter often enough, sooner or fewer a Shakespeare text will eventually emerge. Applied to a language model, this means: it is not a single perfect throw that decides the outcome, but ten thousand throws. In addition, you need someone to pick out the correct ones from these ten thousand. Smaller models like Llama 3B, 7B, or 8B still lagged behind the then-current GPT-4o with a single attempt at an answer. But when enough samples per task were generated and subsequently checked, they pulled ahead.

As an aside: Today, the same models also solve tasks that are only described in the prompt rather than being backed up with training data. This is known as „few-shot“ or „zero-shot“, and it explains why an AI system today can do more than mere text completion. Before that, however, it is worth looking at the mechanics behind the monkey theorem itself. It is about the interplay of generation and verification.

From question catalogue to examiner: how RLHF and verification interact

The RLHF loop in four steps

RLHF stands for „Reinforcement Learning from Human Feedback“. Together with instruction tuning, it was the crucial ingredient that turned a mere text completion tool into an interactive artificial intelligence. The process behind it is more pragmatic than the term suggests and runs in four steps.

1. The model generates multiple candidate answers for one and the same question.
2. People, some of whom are experts and some ordinary users, evaluate these candidates based on criteria such as correctness, usefulness and harmlessness, deciding which answer is better and which is worse.
3. An own model is trained from precisely these reviews, the so-called reward model. It thereby learns to automatically replicate human preferences.
4. In a further training step, this reward model then controls the parameters of the actual language model in such a way that responses which would receive a high rating are more likely to be generated in future.

The result is a model that no longer just outputs „something plausible“. It is intended to align with human values and preferences.

Verification: a second, often underestimated instance

The RLHF loop happens once, during the training of a model. To be distinguished from this is a second mechanism. This comes into play with every single request after training has long been completed: verification. Instead of outputting one response, the model generates many. A separate selection mechanism then decides which of these is actually issued.

In verifiable domains such as program code or mathematics, this selection mechanism is remarkably sober: unit tests. Each of the generated code variants runs against automated tests, and the one that passes all tests wins. In non-verifiable domains, such as running text or creative writing, there is no automated „right“ or „wrong“. Here, a second language model acting as a judge takes the place of the unit test: „LLM as a Judge“.

The generator-verifier gap

Why is all this effort of multiple generation even worth it? Because generating is cheap and checking is expensive. A model can produce thousands of plausible-sounding answers in a short space of time. Whether the answers are actually usable is another question. In the „Large Language Monkeys Project“, this had to be taken quite literally for some of the most difficult tasks: among ten thousand artificial intelligence-generated solutions for a single problem, sometimes only three or four were actually correct. However, as long as the verifier can reliably distinguish between these few correct ones and the many incorrect ones, that is enough. If the verifier is poor or simply too slow (human), the checking itself becomes the bottleneck rather than the generation.

The approval process has known the principle for ages — just without a memory

Now to the ERP system that actually occupies most readers of this blog. SAP Business One has with the Approval process a feature on board that does its job unobtrusively: if a receipt violates a stored rule (such as a discount of ten percent or more), it is not simply processed. The system holds it until a supervisor approves or rejects it.

You can read this mechanism as a very simple, human-driven verification: the system generates a candidate (the document), and an approver decides whether it passes. Structurally, this resembles the role assumed by the reward model in the RLHF loop – a human evaluates, the system reacts to this evaluation. However, the crucial difference lies precisely where it gets interesting: it follows from the described mechanics that the approval process in SAP Business One does not learn from any single sign-off. Whether the manager approves or rejects today does not make the system any wiser for the next, structurally identical request. With all due respect, it remains the patient reviewer who starts from scratch after every single case. In RLHF training, a reward model shapes an independent, reusable evaluation model from precisely such human judgements.

Rules are not yet artificial intelligence

It is not uncommon in sales conversations for precisely this difference to be glossed over or skipped: a rule-based system quickly sounds „intelligent“ in its description. However, it is fundamentally different from a system that learns from evaluations.

Anyone already familiar with this will find a second function that fits into this perspective: the alarm functions. They automatically notify users of commercial discrepancies – budget overruns, falling below minimum inventory levels, exceeded credit limits – either via predefined rules or a custom SQL query. This can also be interpreted as a rule-based counterpart to verification: both automatically filter discrepancies out of a larger pool. The difference from verification in the AI context, however, is that here there is no pool of many generated variants from which the system selects. Rather, the alarm function checks a single, already established state against a fixed rule, rather than comparing multiple candidates against each other.

An additional criterion in the rulebook — and a switch that decides in graded steps

At this point, one can easily go a step further, expressly using the subjunctive, because none of the following exists as a function, and no one is announcing here that they are going to build such a thing. The approval process in SAP Business One could not only be observed, but also extended. This does not concern an additional layer alongside the existing rules, but extensions within the set of rules itself that currently triggers the approval. Currently, the sole deciding factor is whether a hard-coded value is exceeded. This could be, for example, a discount of ten percent or more. It is conceivable that alongside such rigid thresholds, another criterion could be introduced that is not derived from a fixed number, but from the history of past approval and rejection decisions. This criterion would not replace what triggers approval today, but would supplement it. It could help determine whether an approval is necessary at all or at which level it ends up.

The difference compared to a fixed threshold lies in what a single number cannot capture. A threshold of ten per cent discount knows only that single number. It does not see whether the same customer, the same combination of position and timing, or the same sales representative was unremarkable or conspicuous in previous cases. A document with an eight per cent discount, which would remain below any fixed threshold, could still be out of the ordinary. Precisely because of the combination of characteristics that deviates from everything that previously triggered an approval. A learned criterion could recognise precisely such combinations and trigger an approval where a rigid rule would remain silent. Or conversely, it could require a higher approval level, even though no single value in itself breaches a limit.

A points instead of a switch

Until now, this criterion sounded like a two-way switch: approval required or not required. However, a finer gradation is conceivable. Instead of triggering in a binary way, the criterion could assess how high the risk of misinterpretation or a rule violation would be in the specific case, and use this assessment as a switch rather than a simple toggle. Cases with a low assessed risk would pass through without further review. Cases with a higher assessed risk would go to a human for review. And in cases where the risk is assessed as very high, the system could require an additional approval level or another reviewing person.

The benefit of such a sorting mechanism would not lie in less auditing overall, but in its distribution. Human auditing time is scarce and is currently spread evenly across all cases that exceed a fixed threshold — regardless of whether the individual case actually deserves attention or merely falls above the threshold by chance. A tiered assessment would shift this attention to where it actually makes a difference and away from where a glance would not change the decision anyway.

The one who sets the points

This changes what would just have to be said about the relationship between the criterion and human decision. Not every single piece of evidence would have to pass across a human desk anymore — that would precisely be the benefit of gradation, and it would be dishonest to conceal that just to keep the human in the picture at every single point. What would remain is a different responsibility, to be distinguished from that:
How the switch is set, meaning which risk level still passes through without review and which does not. That would not be a decision made by the system, but by a human. This responsibility would lie at the level of the rule, rather than at the level of the individual document. Anyone who interprets the threshold for „low“ generously is thereby deciding in advance on many individual cases at once, without ever having seen a single one of them.

The catch would remain the same as with any learning system, only with an additional facet. It would not only learn from good judgements, but also from careless ones. A manager who routinely waves through discounts without a closer look due to time pressure would write this negligence into the criterion, not turn it into a virtue. A misconfigured set of points would have its own, second failure mode: it would let precisely those cases pass unnoticed for which the approval process was originally established.

Who it's worth it for

This article is aimed at managing directors and CFOs working with SAP Business One who want to understand the technology behind the AI terminology in consultant and software proposals before deciding on budgets or the level of automation. Anyone who does not use SAP Business One can usually substitute this with any other ERP system. Either way, the clarification of terms regarding RLHF and verification is worth reading regardless.
The approval process in SAP Business One is not made any smarter by any of these comparisons. But anyone who knows the difference between a fixed rule and a learning reward model also has a yardstick for deciding which of their own process ideas can now be boldly thought through to the end using artificial intelligence.