A good BoQ CSV export is a plain-text table in which every row is one measured item, with a stable reference, a description, a unit and a quantity. Add a unit rate and a total only if the recipient needs pricing. Before you send it, confirm that CSV is the format the employer, design team or main contractor has actually asked for, and open the file in a text editor to check it. This guide covers the columns to include, the formatting problems that corrupt numbers, a pre-issue checklist, and the cases where CSV is the wrong choice.
TL;DR
- Minimum columns: item reference, description, unit, quantity. Add rate, value and a rate source if you are issuing priced information.
- CSV carries data only. It has no formulas, formatting, sheet structure or drawing links, so those must be handled separately.
- Check the project's information requirements first. CSV is not interchangeable with XLSX, PDF or IFC.
- Open the finished file in a text editor, not just a spreadsheet, and reconcile the totals against your source BoQ.
- Agree what descriptions, units and classifications mean with the recipient. A valid file can still be misread.
Table of Contents
- What a BoQ CSV export is for
- Which columns to include
- Formatting rules that stop numbers breaking
- Check the project's requirements before you issue
- Step by step: exporting a BoQ to CSV
- Pre-issue checks that catch most errors
- CSV, XLSX, PDF or IFC: choosing the right format
- Keeping quantities traceable after export
- Where QuantiFlow fits
- FAQ
- Sources
What a BoQ CSV export is for
A bill of quantities is normally a formatted document: section headings, item descriptions, units, quantities, and sometimes rates and extensions. A CSV strips that down to rows and columns of text. That is exactly why it is useful. It moves into estimating packages, cost databases, procurement tools and reporting dashboards without anyone retyping it.
Typical reasons a QS exports a BoQ to CSV:
- Loading into an estimating or cost-planning system that imports line items.
- Passing quantities to a subcontractor or supplier who prices in their own template.
- Feeding a client's cost database or dashboard where the employer specifies a structured exchange.
- Archiving a clean, software-independent copy of the measured data alongside the signed-off PDF.
The same plainness is the limit. A CSV cannot hold the bold section headers, the preambles, the page layout or the contractual wording that a tender BoQ relies on. If the recipient needs those, you are issuing a document, not a data file. Our guide on which bill of quantities format to use covers that decision in more depth.
Which columns to include
There is no single universal CSV schema for BoQs in the UK, so start from a published one. The Environment Agency's Bill of Quantities Exchange specification, dated 7 March 2025, is a practical checklist even if your project is not an Environment Agency one. It names the fields ItemRef, ItemDesc, ItemType, Quantity, Unit, RateGBP, ValueGBP and RateRef.
The same specification sets some useful limits. ItemRef is text of up to 50 characters, ItemDesc is up to 150 characters, and Quantity and RateGBP carry two decimal places. ValueGBP is defined as RateGBP multiplied by Quantity.
Translated into a working column set:
| Column | Purpose | Notes |
|---|---|---|
| ItemRef | Stable unique reference for the line | Treat as text. Never reuse a reference for a different item. |
| ItemDesc | Measured item description | Keep within the recipient's character limit. |
| ItemType | Separates, for example, measured items from provisional sums or preliminaries | Only if the recipient's schema asks for it. |
| Unit | m, m², m³, nr, item and so on | Use one consistent spelling for each unit. |
| Quantity | The measured quantity | Fixed decimal places, no thousands separators. |
| RateGBP | Unit rate in pounds | Only for priced issues. |
| ValueGBP | Rate multiplied by quantity | Calculate it, then check it. |
| RateRef | Where the rate came from | Library, quotation, previous project. |
Why a rate source matters
The Environment Agency's model keeps RateRef separate from the rate itself. This is an easily missed point in simple exports. A receiving QS who sees £84.50 per m² has a number. A QS who also sees that it came from a named quotation or a dated rate library has something they can check. If you are issuing priced data, include a source column, even if the recipient's template does not demand one. If their import cannot accept extra columns, keep the fuller version for your own records.
Section structure and NRM2 references
A flat CSV has no sections. If your BoQ is organised by NRM2 work sections, carry that structure into the data rather than losing it. Two common approaches:
- Encode it in the item reference, so that a reference such as a work-section prefix followed by a sequence number sorts correctly and groups by trade.
- Add a separate section or group column, which is safer when the recipient's system limits reference length.
Whichever you choose, say so in a short covering note. Without that, the recipient has to reverse-engineer your numbering.
Formatting rules that stop numbers breaking
CSV looks simple, but most failed imports come from a handful of formatting faults. RFC 4180, published in October 2005, is the nearest thing to a formal description of the format. It records that fields containing commas, double quotes or line breaks should be enclosed in double quotes. For a BoQ that matters, because item descriptions are full of commas.
A description such as Concrete grade C25/30, poured in situ, to foundations contains two commas. Unquoted, an importer reads it as three fields and every column to the right shifts. Most export tools quote correctly. Hand-edited files and files built by concatenating strings often do not.
Checklist of common faults
- Commas inside descriptions. Make sure those fields are quoted.
- Thousands separators in numbers. Write 12500.00, not 12,500.00. A comma inside a quantity will either split the field or be read as text.
- Currency symbols in value columns. Keep £ out of RateGBP and ValueGBP. The column name already states the currency.
- Inconsistent decimal places. If the recipient specifies two, give two everywhere.
- Line breaks inside descriptions. Multi-line item descriptions are a frequent cause of rows splitting. Replace them with a space or a semicolon.
- Text references converted to numbers or dates. Spreadsheet programs may reinterpret references such as 1-2 or 03/04 when you open and re-save the file. This is a reason not to round-trip a CSV through a spreadsheet unless you must.
- Special characters. Symbols such as m², m³, ø and the degree sign can display wrongly if the file encoding does not match what the receiving software expects. Ask the recipient which encoding they want, and where it is not specified, test with a small file first.
- Blank trailing rows or columns. These can create phantom items on import.
The practical test is simple: open the file in a plain text editor. You should be able to see exactly what the importing software will see, with quotes, separators and line endings in plain view.
Check the project's requirements before you issue
CSV is a convenient format, not a universal one. The Department for Education's Exchange Information Requirements list formats such as IFC-SPF, PDF and XLSX for defined deliverables and tie delivery to the project's information requirements and milestones. A CSV may carry quantities and rates very well, but it does not on its own satisfy a requirement for model, document, asset or handover information.
So the order of work is:
- Read the employer's information requirements or the information delivery plan, if one exists.
- Identify which deliverable your BoQ belongs to, and what format and milestone are named.
- Ask when it is unclear. Agree the required output with the employer, design team or main contractor rather than assuming CSV, Excel or IFC can stand in for one another.
- Record the agreement in writing, even if only as an email.
This is a communication task as much as a technical one. Guidance on confirming deliverables and milestones with the project team sits within general project quality and communication management, and the principle applies directly to BoQ issue: agree what is being delivered, in what form and by when, before the file is built.
Syntax is not enough
Research from the University of Reading on integrating syntax, semantics and pragmatics in costing practice describes BoQ production as a knowledge-based, dynamic and collaborative process. Applied to CSV, the point is that a file can be syntactically perfect and still be misunderstood. Both parties need to agree what each description, unit, classification and price means in the context of the project. Does "nr" mean the same as "No"? Is a provisional sum a quantity of one with a rate, or a value only? Does the rate include overheads and profit?
A one-page data dictionary answers those questions. Put it in the covering email or in a second file next to the CSV.
Step by step: exporting a BoQ to CSV
The menu names differ between tools, but the sequence is the same.
- Freeze the BoQ. Export only from a signed-off or clearly versioned BoQ. A CSV carries no revision history of its own.
- Decide the column set. Use the recipient's schema if they have one. If not, start from the table above.
- Clean the descriptions. Remove line breaks, check for stray quotes and keep within length limits.
- Fix the number format. Fixed decimal places, no thousands separators, no currency symbols.
- Export. Use the CSV option in your software, or save the one sheet as CSV from a spreadsheet. If your workbook has several sheets, remember that a CSV holds one table only, so you may need one file per sheet.
- Inspect in a text editor. Check the header row, quoting and delimiters.
- Test import. Where possible, load it into a blank copy of the target system or ask the recipient to test a short sample.
- Reconcile. Compare the row count and the sum of quantities and values with the source BoQ.
- Name and log the file. Include project, revision and date in the file name and record what was issued and to whom.
If your starting point is a spreadsheet, our article on getting a BoQ into Excel without wrecking the numbers covers the traps that arise before the CSV stage.
Pre-issue checks that catch most errors
Because a CSV has no formulas, any error in the numbers goes out as a hard value. Build a short control routine.
- Row count. Does the number of data rows match the number of items in the source BoQ?
- Total check. Does the sum of ValueGBP match the BoQ total? Recalculate the extension for a sample of lines.
- Unit check. Filter the unit column for unique values. Misspellings and variant forms show up at once.
- Duplicate references. Sort by ItemRef and look for repeats or gaps.
- Empty fields. A line with a quantity but no unit, or a unit but no description, will cause trouble downstream.
- Negative or zero quantities. Confirm each one is intentional, such as an omission, and not a formula fault.
- Rate source. Confirm each priced line has a traceable rate source.
These checks sit alongside the wider review of the BoQ itself. Our seven BoQ review steps and the list of common BoQ errors to avoid cover the measurement and contract-level checks that should come before any export.
CSV, XLSX, PDF or IFC: choosing the right format
| Format | Best for | Weak at |
|---|---|---|
| CSV | Importing line items into estimating, cost or procurement systems | Layout, formulas, multiple sheets, contractual wording |
| XLSX | Pricing by tenderers, working analysis, multi-sheet workbooks | Strict machine import where structure varies |
| The signed-off, fixed record and tender documents | Reuse of the data | |
| IFC | Model-based information exchange where specified | Not a BoQ format as such |
A common and sensible pattern is to issue the PDF as the record, the XLSX for tenderers to price, and a CSV where a system needs structured import. What matters is that all three come from the same frozen BoQ, so the figures cannot diverge. For the contractual side, see how construction contracts use a BoQ.
Handover data is a related case. Cardiff University research on information requirements in digital construction reported that over 90% of the information handed over on completion in the study was in flat file formats, with a loss of the relationships between data. That is a warning about relying on flat files alone when the employer needs structured asset information.
Keeping quantities traceable after export
Once a quantity is in a CSV, its link to the drawing is gone unless you keep it deliberately. Two habits help:
- Add a drawing reference and revision column where the recipient's schema allows it, or keep a mapping file in your own records.
- Keep the source measurement record with the issued file, so that a query on a line can be traced back to the drawing revision it was measured from.
We set out the thinking in linking each BoQ line to its drawing revision. If a drawing is revised after you issue the CSV, the file does not update itself. Reissue with a new revision identifier and say what changed.
For priced exports, see also our practical guide to BoQ pricing, and the bill of quantities example if you want to see how a finished BoQ is laid out before you flatten it into rows.
Where QuantiFlow fits
QuantiFlow is a product in development that reads construction drawings and produces a draft bill of quantities for a quantity surveyor to review and sign off. The review stays with you, and so does the decision on which format goes to whom. Current plans are listed at quantiflow.co.uk: Solo at £69 per month, Business at £299 per month, and Enterprise with no published price.
FAQ
What columns should a BoQ CSV have?
At minimum, an item reference, a description, a unit and a quantity. For priced issues, add a unit rate and a total value, and ideally a rate source. The Environment Agency's 2025 exchange specification is a useful model, with fields for reference, description, type, quantity, unit, rate, value and rate reference.
Can I just save my Excel BoQ as CSV?
Yes, but only after tidying it. A CSV holds one sheet, no formulas and no formatting, so remove merged cells, headers, subtotals and line breaks first. Then open the saved file in a text editor and check the quoting and numbers before you send it.
Is CSV acceptable for a tender or contract BoQ?
It depends on the employer's requirements. Some projects specify XLSX, PDF or IFC for particular deliverables, and CSV does not automatically meet those. Check the information requirements or ask the employer, design team or main contractor, and keep the answer in writing.
Why do my descriptions split across columns after export?
Usually because descriptions containing commas were not wrapped in double quotes, or because they contain line breaks. Fix the quoting, remove the line breaks and export again. A text editor shows the fault immediately.
Sources
- Bill of Quantities Exchange, Environment Agency (7 March 2025)
- Exchange Information Requirements, Department for Education
- RFC 4180: Common Format and MIME Type for CSV Files (October 2005)
- Integrating syntax, semantics and pragmatics for computer-aided professional practice, University of Reading
- A framework for the integration of information requirements within infrastructure digital construction, Cardiff University
- Project Quality and Communication Management
Recommended
- Getting a BOQ into Excel without wrecking the numbers
- Which bill of quantities format should you use?
- Seven BoQ Review Steps for UK QSs, Tied to Standards and Contracts
- 10 BoQ Errors to Avoid: Audit Controls for Practising QS
This article is for general information only and is not professional, legal or commercial advice. Quantity surveying decisions should be taken by a qualified professional with reference to the specific project, drawings and contract in question. Content is produced with AI assistance and reviewed before publication. QuantiFlow Ltd accepts no liability for reliance on it.