GAEB file formats explained: GAEB 90, 2000, and DA XML (D81–D86)

If you work with German construction tenders, you have met GAEB files — and probably cursed at least one of them. They arrive with extensions like .d83, .x83, .p83, or .gaeb, and whether your software opens them cleanly is mostly luck. This post explains what those formats are, how they differ, and why the same bill of quantities can appear in several incompatible shapes.

What GAEB is

GAEB (Gemeinsamer Ausschuss Elektronik im Bauwesen) is the German standard for exchanging commercial construction data — bills of quantities (Leistungsverzeichnisse), tenders, bids, and awards — between the parties in a project. Instead of emailing a PDF that has to be retyped, the client's software exports a structured file, and the contractor's software reads it back. That is the promise. The reality is three generations of the standard living side by side.

The three format generations

GAEB 90 is the oldest format still in circulation. It is a fixed-width, line-based text format — every record sits at defined character positions. It is compact and unambiguous once you know the layout, but it has no real support for formatting, long texts, or Unicode, and it is unforgiving of the smallest deviation. Files usually carry extensions like .d81 through .d86.

GAEB 2000 modernised the structure and added richer text and formatting, but it is a transitional format you still occasionally receive from older estimating systems.

GAEB DA XML is the current standard (DA stands for Datenaustausch, data exchange). It expresses the same information as XML, which makes it far more expressive — long texts, markup, execution descriptions, and metadata all have a proper home. Files use extensions like .x81–.x86 or .X83. When people say "the modern GAEB format," this is what they mean, and it is what most new tools target first.

The trap: all three can describe the same tender. A single manufacturer might receive GAEB 90 from one architect and DA XML from the next, for functionally identical work.

The D81–D86 exchange phases

The number after the D (or X) is not a version — it is the phase of the tendering process the file belongs to. This is the part that trips people up most:

In practice, a manufacturer most often receives a D83 (the empty priced-out request) and has to return a D84 (the same structure with unit prices filled in). The positions, order, and identifiers must match exactly — the client's software reconciles your D84 against its original D83 line by line.

Why this matters for estimating

Every one of these variations is a place where a workflow breaks:

• An estimating tool that reads DA XML but not GAEB 90 forces someone to retype the older files by hand.
• A subtle encoding or position mismatch in a D84 can make the whole bid unreadable to the client — after hours of pricing work.
• Long execution texts survive in XML but get truncated when a tool downgrades to an older format.

Once you can name a file by its generation and phase, the remaining problem is software that only speaks one of them. That is the whole reason our open-source parser pyGAEB exists — it reads every GAEB generation and exchange phase into one clean, typed model, so tools stop caring which shape a tender arrived in.

If you only remember one thing: the letter tells you the generation (90 vs XML), the number tells you the phase (request vs bid vs award). Get those two straight and most GAEB confusion disappears.