Why a GAEB file won't import: the 10 most common errors

A tender arrives, you drop it into your estimating software, and it fails — or worse, it imports and the numbers are wrong. The deadline does not move. The first question is not "how do I fix this file"; it is whose problem is this, because the answer decides whether you spend the next hour on your own settings or on an email to the sender.

This post is the triage. Ten things that actually go wrong, what each one means, and which ones are worth sending back.

First: sixty seconds to find out whose problem it is

Take our free sample GAEB file — a clean DA XML 3.3 X83 with 22 positions — and import that.

• The sample imports, your file doesn't → the problem is in the file. Read on, then send the sender a corrected-file request.
• Neither imports → the problem is on your side: the wrong import profile, an unsupported GAEB generation, or a version of your software that predates DA XML 3.3.
• Both import, but your file's numbers look wrong → nothing crashed; something is semantically off. Sections 3, 6 and 7 below are the usual suspects.

Then run the file through GAEB-Check. It reads the file in the browser, groups every finding by kind, and uses the same names as the table below — nothing installed, nothing stored.

The ten

Six of those deserve more than a row.

1. Duplicate position numbers — the one that really breaks things

Every tool on both sides of the exchange identifies a position by its OZ (Ordnungszahl). When the same OZ appears three times, an importer keeps one and drops the others, a price import writes to the wrong row, and the client's reconciliation of your bid against their request silently mismatches. You can lose positions without any error message at all.

This is the single finding worth stopping for. GAEB-Check reports it as an error with the affected numbers; ask for a corrected file rather than working around it, because any workaround you invent will not survive the round trip back to the client.

2. The phase doesn't match the extension

The number in the extension is the exchange phase, not a version: 83 is a request for bids, 84 is a bid with prices, 86 is the award. Inside the file there is a <DP> element that states the same thing — and when someone does "save as", the extension changes and the <DP> does not.

The symptom is confusing: an X84 renamed to .x83 imports as a request, and every price in it is discarded without a word. GAEB-Check prints the phase it found in the first line of the result; compare that with the extension you were sent. If they disagree, believe the <DP>. The formats guide has the full X80–X89 table.

3. Positions without a quantity — usually not an error

This is the finding people most often panic about, and it is most often fine. Two legitimate cases:

• Measured on site (nach Aufmaß) — the quantity genuinely is not known yet.
• Lump sum (Pauschal) — there is nothing to multiply.

Our sample file contains one of each, deliberately, so you can see how your tool handles them. Price the unit and mark the quantity as open in your bid. Only worry if a position that clearly should carry a quantity is empty — that is a drafting mistake worth a question.

6 and 7. Totals that don't add up

Two different findings that people confuse:

• Position level: the stored total does not equal unit price × quantity. Someone typed over a total after the quantity changed. Recompute before you price or compare.
• Title or bill level: the declared subtotal or grand total does not match the sum of the positions under it. The same cause, one level up. Trust the position totals, not the declared sum — the positions are what the client reconciles against.

A special case worth knowing: a bid whose positions carry unit prices but no position totals is not a zero-value bid. Some software writes it that way. Recompute from quantity × unit price and you have the real number.

8. Schema errors that don't actually matter

If your checker validates against the official GAEB schemas, you may see complaints about element order in the file header — an element in the wrong place, one the schema expected first. These almost always come from software that predates the current schema, and the bill of quantities itself reads fine.

Judge them by where they are. Header order problems: note them, carry on. Problems in the positions: take them seriously. A strict procurement platform may still reject the file on submission, which is worth knowing before you send your bid rather than after.

10. It isn't DA XML at all

A .d83 is GAEB 90, a .p83 is GAEB 2000 — different generations of the standard, not different versions of the same file. If your software only reads DA XML, no import setting will help.

Be aware of our own limit here: GAEB-Check and pyGAEB read DA XML (2.0 through 3.3); GAEB 90 is on the roadmap and not shipped. So for a .d83 we are no help either. Ask the sender for the same bill of quantities as DA XML — every current AVA package can export it, and it takes them a minute.

What to write to the sender

Most senders are not being difficult; their software exported something they never looked at. A specific request gets a corrected file within a day, where "it doesn't work" gets a phone call.

Subject: Tender [number] — GAEB file cannot be processed

Dear [name],

thank you for the tender documents. Unfortunately I cannot import the GAEB file [filename]. The following came up when checking it:

• position number 01.0020 appears three times; each position number must be unique, otherwise prices cannot be assigned reliably
• the file is named .x83, but internally declares phase 84
• 12 positions have no long text, so the specification is missing

Could you please send a corrected file as GAEB DA XML (.x83)? Everything else is ready on our side and we would like to keep to the submission date of [date].

Best regards,

Delete what does not apply, paste in the position numbers GAEB-Check lists. Naming the exact positions is what turns a complaint into a fix.

When the file is fine and it still won't import

Then it is a profile question on your side. In order of likelihood: your software's import profile is set to the wrong GAEB generation; it predates DA XML 3.3 (published 2021) and rejects the newer schema; or it is refusing on a warning that a more tolerant reader would let through. The four ways to open a GAEB file covers what to do while you wait for an update — including reading the file well enough to price from it, even when your main tool will not take it.

And if you are handling this more than once a month, that recurring hour is worth automating rather than repeating.