B2B Approval Workflows and Budget Control in Shopware

In B2C, one person decides and buys. In B2B the order is often a collective act: an employee needs something, a manager approves, purchasing checks the budget, accounting books it. Gartner finds that a typical B2B buying decision today is carried by five to sixteen people across as many as four functions (Gartner, 2025) - each with its own perspective and its own need to approve. A store that ignores this reality does not fit its customers' internal processes. The consequence is predictable: purchasing bypasses the store because approval cannot be mapped there.

That this break is costly is shown by Gartner's conflict research: 74 percent (Gartner, 2025) of B2B buyer teams show unhealthy conflict during the decision, and teams that reach a consensus report a high-quality deal 2.5 times (Gartner, 2025) more often. A clearly defined approval workflow in the store channels exactly this coordination: who may order, who must approve, from what amount purchasing steps in. This turns the store from a mere order channel into a tool for internal governance. How such processes can be digitised as a whole is covered in our article on digital sales processes in B2B.

The core of an approval workflow is the question: when must who approve an order? In practice this depends on several dimensions. The most common is order value: up to a certain amount an employee may order directly, above it a team lead must approve, and from a higher threshold purchasing or management steps in. These amount thresholds are not a theoretical construct - they mirror the internal signature rules that exist in almost every company. A good B2B store maps them one to one instead of forcing customers to maintain a second approval system in parallel.

Besides the amount, role and cost centre matter. A buyer in the role of purchaser has different limits than a technical employee who only orders consumables. An order against a project cost centre may trigger a different approval chain than an order for ongoing operations. How roles, permissions and customer groups are modelled in Shopware in principle is described in our article on customer groups, roles and permissions - it forms the foundation on which approval workflows build. Only this cleanly maintained role structure makes it possible to assign approvals precisely.

Approvals govern who may order. Budgets govern how much may be spent in total. The two interlock. A budget pot is assigned to a department, a project or a cost centre and given a limit. Every order reduces the available budget, and when thresholds are reached the behaviour changes: up to a certain utilisation the order goes through, above it the order is flagged for review, and when the budget is nearly exhausted it is blocked. This prevents an overrun before it happens instead of correcting it afterwards in accounting.

The relevance is considerable. The Hackett Group reports that in organisations without effective controls up to 80 percent (Hackett Group, 2025) of spend can run off-contract, and finds that 64 percent (Hackett Group, 2025) of procurement leaders are dissatisfied with how they handle so-called tail spend. Deloitte estimates that 20 to 30 percent (Deloitte) of spend in many organisations falls into uncontrolled tail spend. Budget control anchored in the store addresses exactly this leak: it makes every order visible, assigns it to a cost centre and stops it before the budget is breached.

An approval rule is only as good as its enforcement. If an order button is merely hidden in the frontend while the associated endpoint remains reachable, the rule can be bypassed with simple means. That is why every approval and budget check must happen server-side: before an order is placed, the backend checks whether the current status has passed all required approvals and whether the budget is sufficient. The frontend only displays the status - the binding decision is made in the backend. This principle applies to the entire B2B store, from prices through assortments to ordering rights.

Technically this means a cleanly modelled order status: an order can be draft, in approval, approved, rejected or placed. Every transition is tied to conditions and is logged. This traceability is not only technically sensible but also a governance argument: the Association of Certified Fraud Examiners finds that the typical organisation loses around 5 percent (ACFE, 2024) of its revenue each year to occupational fraud, and that more than half of cases are correlated with a lack of internal controls or their override (ACFE, 2024). A traceable, server-side enforced approval process is thus also a piece of fraud prevention.

An approval process that runs in the dark slows purchasing down. Sana Commerce finds that nearly 70 percent (Sana Commerce, 2025) of B2B shopping carts are abandoned online, and names complex, opaque processes as a recurring cause. An approval that hangs for days without feedback feels just like a lost cart. That is why every workflow needs clear status displays and active notifications: the buyer sees which stage their order is in, and the approver is informed that an approval is waiting for them.

On top of this comes the topic of deputies. Approvers go on holiday, fall ill or are overloaded. A workflow that then blocks is unusable in everyday life. Deputy rules, escalations after a defined waiting time and the option to delegate an approval make sense. This mechanism is closely related to the quoting process, which also involves several parties - how the path from quote to order looks is shown in our article on quote management and quote-to-order. Forrester expects that more than half of large B2B transactions will be handled through digital self-service channels (Forrester, 2025) - without transparent approvals this does not work.

Approving an order and approving the payment are two different things that often interact in B2B. An order can be approved in substance but held back by a credit limit. Especially with buying on invoice, the credit limit is its own control layer: it caps how much a customer may order open on invoice, independent of the internal approval chain. How buying on invoice, credit limit and payment approvals interlock is covered in our article on payment methods, buying on invoice and credit limit.

That the payment term itself is a reason for abandonment is backed by research. A report by Sapio Research commissioned by Sana Commerce shows that 73 percent (Sana Commerce, 2025) of buyers want to order online, but 81 percent (Sana Commerce, 2025) face significant barriers from outdated systems and inaccurate data. When a customer notices at checkout that neither their usual payment term nor their internal approval can be mapped, they drop out. A well-considered combination of order approval and payment approval holds both worlds together: the customer's internal governance and the supplier's commercial protection.

Approval processes and budgets are not a pure store matter. They touch the ERP, where cost centres, budgets and credit limits are maintained, and accounting, which books the orders. An isolated solution in the store that knows nothing about the budget levels in the ERP inevitably leads to two truths. That is why a robust concept includes the question of which system leads the budgets and how they are kept in sync. Often budget authority lies in the ERP, while the store maps the consumption and reservation logic in real time and feeds orders back.

For this to work robustly, a well-considered integration is needed. Which data the store leads and which the ERP, how failures are handled and how real-time queries stay performant is described in our article on interface architecture in B2B. The concrete connection to the leading system is the topic of our article on ERP integration. Only when approval, budget and ERP interlock do individual functions become a continuous, trustworthy purchasing process - and this integration is exactly what we implement as custom development in our services.

No approval process is like another. Some need a simple four-eyes check, others a multi-stage chain with budget pots, deputy rules and escalations. That is precisely why approval workflows are a field for custom development rather than templates. On the basis of Shopware as open source, a workflow model can be built that maps the specific signature rules, cost centres and budget logic of a company without forcing the customer into a rigid corset. The open-source basis ensures the logic stays traceable, extensible and in your own hands.

The path there begins with understanding the customer's internal processes: who orders what, who approves, from what amount, against which budget. From this analysis a workflow model emerges that we implement in Shopware and connect to ERP and accounting. How we accompany such digital purchasing processes from analysis to implementation is shown in our article on digital sales processes. Concrete project approaches and competency fields can be found in our references. The goal stays the same: to turn internal purchasing rules into low-friction self-service that gives customers more control and secures suppliers more orders.