GAEB, SAP Ariba, and the converter myth: Why conversion is no substitute for a sourcing process

Many companies in construction and project purchasing now work with a similar system landscape: SAP S/4HANA as the central ERP system, the data model Lean Services with Item Hierarchies for complex services, and SAP Ariba for the sourcing process.

However, as soon as construction or project-oriented procurement comes into play, a key question arises: How can GAEB-based item lists be integrated into this architecture?

The most common answer is: "We just use a GAEB converter." Technically, this is entirely possible. But this raises a crucial question: What role does such a converter actually play in the sourcing process?

Procurement in construction projects: Practical requirements

In construction and project procurement, the procurement department regularly uses specifications in GAEB format. These form the basis for tenders, bid comparisons, and award decisions.

In practice, the procurement process involves a wide range of tasks: Issuing requests for Item lists, comparing quotations from several suppliers, and conducting negotiations. In addition, there are several rounds of requests and quotations, multiple versions of a request, the awarding of lots, and the management of supplements and budgets

When it comes to construction projects, there is one simple reality:
Supplements are the rule rather than the exception.

In order for controlling and project management to function reliably, changes in quantities and prices must remain traceable at all times. If SAP is the leading system in the company (digital core), this transparency and traceability should ideally be reflected there as well.

GAEB is more than just an exchange format

A GAEB-based item list is not a simple document. It contains a structured logic of lots, titles, items, hierarchies, and various item types, e. g. alternative and contingent items. This structure is supplemented by quantities, unit prices, and – most importantly – the ordinal numbers (OZ), which enable the unique assignment of items in the item list.

This information is crucial for central purchasing functions such as quote evaluation, price comparisons, award decisions, and budget control.

This raises a key question in every system architecture:

❓Where is this technical structure with the ordinal numbers of the item list actually processed and understood in the procurement process?

Typical architecture with GAEB converters

The converter handles several technical steps: It reads the structure of the GAEB-based item list (parsing), assigns the items to the data structures of the sourcing system (mapping), and then converts incoming quotations back into GAEB format.

Data flow with a GAEB converter:

▶️ GAEB file ➡️ GAEB converter ➡️ SAP Ariba 🛑 S/4HANA

Data exchange works. However, this means that the business logic of the item list lies outside the actual sourcing system – namely in the converter itself. And this has significant consequences.

Since SAP Ariba does not natively understand the GAEB structure, the actual sourcing process in this architecture ends in the Ariba system. There are no plans for end-to-end processing of the structured item list data in SAP S/4HANA.

In particular, purchase orders or contracts for “Lean Services with Item Hierarchies” cannot be created directly in SAP S/4HANA, as the hierarchical item list required for this is not fully available in the SAP system.

Although the process appears to be technically integrated, it is in fact more of an “end-to-stop” process: Sourcing and quote evaluation take place in SAP Ariba – if possible – while operational procurement and controlling must then be continued separately in SAP S/4HANA.

In construction and project procurement, the price index is the key analytical tool. It serves as the basis for structured bid comparisons and helps purchaser make informed award decisions.

Typically, a price comparison enables:

• Structured quote comparisons
• Utility analyses
• Budget control
• Scenario comparisons

SAP Ariba provides functions such as bid comparison and bid analysis for this purpose.

In order for a price comparison table to display offers in GAEB format correctly, the system must understand the technical structure of the service specifications. This is not the case in SAP Ariba for the following reasons:

• No management of ordinal numbers (OZ)
• No mapping of multi-level, GAEB-compliant item lists
• No support for GAEB-compliant item types
• Performance issues with larger item lists
• etc.

If the price comparison list is not available in SAP Ariba, it must also be mapped in the converter. In this respect, the converter is taking on more and more logic.

In practice, many purchasing organizations also expect additional options. It is often required that a price comparison table can be exported to Excel—including the underlying formulas. This is the only way to flexibly process complex scenarios, utility analyses, or budget comparisons.

After all, Excel without formulas is ultimately not a price comparison table. It's just a spreadsheet.

3️⃣ Versioning of bidding rounds

In construction and project purchasing, several request rounds are common. A typical process includes an initial quotation, one or more rounds of clarification and negotiation, and finally a last bid.

To enable purchasers to compare quotations meaningfully, the price comparison must be versioned across these rounds. This is the only way to track

• how prices change between bidding rounds
• which items have been modified
• how quotations develop over time

The structural consistency of the item list plays a decisive role here. Only if the structure remains stable can price changes be correctly analyzed and compared with each other.

Converter architectures therefore raise an additional question:

❓Where are the versions of the item lists actually managed?

When a GAEB converter processes and manages the structure of the item list, it inevitably has to take on additional tasks – such as saving versions of the item list, synchronizing bidding rounds, and ensuring the traceability of changes between each round.

This means that the converter no longer performs only a technical function, but also takes on parts of the specialist process logic of the procurement process. In other words, purchasers will then work in SAP Ariba and also in the converter, always with the residual risk of data inconsistencies because the structure of the quotations does not match the item list.

Requirements for the sourcing system

The aspects discussed so far primarily highlight the role of a GAEB converter. This raises a further question:

❓What requirements must the sourcing system itself – for example, solutions such as SAP Ariba?

Particularly in construction and project purchasing, such systems must be capable of processing extensive item lists and, crucially, ordinal numbers (OZ), while also working with the data structures of the ERP system.

Two aspects play a key role here:

✴️ Size and complexity of the item lists

GAEB-based item lists can be very extensive. In many projects, around 1,000 items are common, and in larger construction projects, five-digit item counts are not uncommon.

This creates complex hierarchical structures consisting of lots, titles, and items, which must be processed and analyzed in the sourcing system. This places high demands on performance, data structure, and analytical capabilities, particularly in the case of quote comparisons and price comparison lists.

The practical question:

❓Up to what size and complexity can item lists be efficiently processed and evaluated within a sourcing tool?

✴️ The SAP data model: Lean Services with Item Hierarchies

There is another aspect to consider in the SAP environment. SAP introduced a hierarchical service data model in S/4HANA called Lean Services with Item Hierarchies, which is designed to map complex services.

However, this model is not directly GAEB-compatible. GAEB-based item lists use a different structure and item logic. In this respect, GAEB item lists must also be transformed into item hierarchies.

This creates another layer of transformation within the system architecture – and potentially additional sources of error in the interaction between GAEB, the sourcing system, the converter, and the ERP system.

Conclusion: It's not the conversion that matters – it's the system architecture.

A GAEB converter can facilitate the exchange of GAEB files.

However, it does not replace a system that:

• Structurally understands item lists
• Processes changes and supplements
• Validates quotations within the system
• Versions price comparison lists
• and links this information directly to Controlling in SAP.

Therefore, one thing is clear: The key architectural question is not:
"Can a system exchange GAEB files?"

The real question is rather:
Where is the specialist logic of the item list processed?
In the sourcing system? Or in the GAEB converter?

For this reason, the FUTURA Smart sourcing solution takes the approach of integrating GAEB specifications directly into the sourcing workflow rather than handling them separately from the procurement process. This ensures that the technical structure of the specifications is fully preserved and can be interpreted and evaluated by the system.

This is the only way to implement a seamless end-to-end process spanning tendering, bid evaluation, award controlling within the SAP system. Instead of isolated data conversions, this creates an integrated process chain in which GAEB structures, procurement decisions, and budget information are consistently consolidated within S/4HANA.

This architectural issue is particularly critical in construction and project procurement, as it determines how transparently quotations can be evaluated and how closely procurement and controlling work together within the SAP system.