What Is ÖNORM A2063? The Austrian Standard for Tender BOQs Explained

Bid on a public or larger private tender in Austria and the Bill of Quantities you receive is very rarely a plain PDF. It follows ÖNORM A2063, the Austrian standard for electronically exchanging a Leistungsverzeichnis (LV) between the party issuing the tender and the contractors bidding on it. Understanding what that standard actually governs matters as much as understanding the numbers in the document itself.

What ÖNORM A2063 Actually Is

ÖNORM A2063 is published by Austrian Standards and defines how a Leistungsverzeichnis, the Austrian equivalent of a Bill of Quantities, is structured and exchanged electronically. It isn't pricing software itself; it's a data format, the same relationship a PDF standard has to any specific PDF reader.

The practical reason it exists mirrors GAEB in Germany: a client or their consultant prepares the LV in professional tendering software, exports it in the standardized format, and sends it to every invited bidder. Each bidder imports that same structured data into their own estimating tool, prices every line, and returns it in the same format. Everyone works from identical structured data instead of retyping a document by hand, and the client's side can compare bids like-for-like because the structure is guaranteed to match.

How an ÖNORM LV Is Structured

Like its German counterpart, an ÖNORM Leistungsverzeichnis is hierarchical rather than a flat list, which is what keeps a large tender navigable:

• Groups and sub-groups, organizing the LV by trade or work area, similar in purpose to how a GAEB LV groups by Titel.
• Positions, the individual priceable line items, each carrying a reference number, a description, a unit, and a quantity.
• Standard descriptions drawn from established Austrian LV text libraries, which is one of the more distinctive features of the Austrian system: many positions reference standardized description text rather than fully custom wording, which keeps terminology consistent across tenders from different issuers.

As with GAEB, the quantities in the LV are already measured by the party issuing the tender. The bidder's job is to price against those quantities, not to remeasure them, which is a materially different workflow than pricing a BOQ built from scratch off drawings.

Why It Matters More in Austria Than It Might Look

Austrian public procurement, governed by the Bundesvergabegesetz, has pushed structured electronic tendering for years, and standardized LV exchange is now the norm rather than the exception on larger public work. Professional Austrian AVA (Ausschreibung, Vergabe, Abrechnung) software, used by architects, engineers, and public bodies, produces and expects this format as a matter of course. A contractor whose estimating tool can't read it directly is stuck manually re-entering hundreds or thousands of positions by hand, on every tender.

Where This Breaks Down Without the Right Tooling

The same failure modes that affect GAEB workflows in Germany apply here:

Manual retyping introduces errors. Copying a large LV into a spreadsheet position by position reintroduces exactly the transcription risk the standardized format exists to prevent.

Losing the group structure. A flat export strips the trade grouping, making it harder to sanity-check pricing section by section before submission.

Formatting mismatches on the return trip. The priced LV sent back has to validate against the format the client's system expects. A malformed export can get a competitively priced bid rejected on a technicality before anyone reviews the numbers.

No pricing data of its own. The LV supplies quantities and descriptions. Current, local labor and material rates for every position still have to come from somewhere else.

How BoqCalc Handles ÖNORM

BoqCalc reads ÖNORM A2063 files directly, preserving the group and position hierarchy rather than flattening it, and suggests pricing for every position using local Austrian market data. The priced output exports back out in a structure ready for submission, with the same reference numbers the client's system sent, avoiding manual re-keying and the formatting risk that comes with it.

For how GAEB, the closely related German standard, works in comparison, see our guide to GAEB files explained.

Frequently Asked Questions

Is ÖNORM A2063 the same as GAEB? No, though they solve the same problem and share a similar hierarchical structure. GAEB is the German (and also used in Switzerland) standard; ÖNORM A2063 is the Austrian one. A tool that supports one doesn't automatically support the other; both need to be handled explicitly.

Do I need special software to open an ÖNORM LV file? Standard Austrian AVA or estimating software with ÖNORM support can open it correctly. A generic spreadsheet program can't parse the structure, so you'd be working with the raw data rather than the intended hierarchy.

Is ÖNORM A2063 only relevant for public tenders? Public procurement is where it's most consistently required, but larger private clients using professional AVA software commonly follow the same convention, since it's the format their tools already produce.

Can I submit a bid in a different format if I received an ÖNORM LV? Technically sometimes possible, but it usually works against the bidder. Many evaluators compare bids using tools that expect the standardized structure returned, and a non-conforming submission can be at a real disadvantage.

Conclusion

ÖNORM A2063 isn't complicated once its shape is clear: a hierarchical LV with quantities the client already measured, positions the bidder prices, and a format built specifically so that round trip doesn't introduce transcription errors. For any contractor bidding regularly in Austria, support for it in an estimating workflow isn't a nice-to-have. It's the difference between bidding on that work efficiently and re-entering every tender by hand.