DPGF, BPU, DQE: reading tender pricing documents

In a tender package, the pricing documents say two things: how the contractor must price the work, and how their bid will be compared with the others. In the French market three acronyms come up constantly — DPGF, BPU, DQE — and they are easily confused. Here is what each one covers, how a price breakdown is structured, and the habits that save hours on a technical package.

What is a DPGF?

DPGF stands for décomposition du prix global et forfaitaire: the breakdown of a global lump-sum price. It details, line by line, how the contractor's lump-sum price is built. The client or design team supplies the template — items, units, usually quantities — and the contractor fills in unit prices. The sum of the lines forms the bid.

One point matters above all: in a lump-sum contract, the lump sum is what binds, not the individual line. The breakdown exists to justify the amount, to compare bids, and later to value variations. It is also the document you will reach for in the event of a dispute — reason enough to treat it carefully.

DPGF, BPU, DQE: telling them apart

The three documents look alike on screen but carry very different contractual weight.

• DPGF — breakdown of a lump-sum price. Quantities are generally provided. The total is the contract price.
• BPU (bordereau de prix unitaires) — a schedule of unit rates without quantities, used for call-off contracts. What gets paid depends on the quantities actually ordered.
• DQE (détail quantitatif estimatif) — a BPU with estimated quantities added, used solely to rank bids. It is not contractual: it is a simulated order.

The practical consequence: on a BPU, a badly set unit rate follows you for the life of the contract. On a DPGF, an error in the quantities supplied by the client can be negotiated — provided you flagged it during the tender period.

How a DPGF is structured

The logic is always hierarchical: package → chapter → sub-chapter → item. Each item line carries at minimum a code, a description, a unit (each, linear metre, m², lump sum), a quantity, a unit rate and a total. Subtotals close each level, and a grand total closes the package.

In MEP, this structure usually mirrors the specification: heating, ventilation, plumbing, smoke control, power, data, fire safety systems. Some design teams add a level per building or per zone, which multiplies the lines but makes site monitoring easier.

The item code deserves particular attention: it is what lets you automatically reconcile your internal estimate with the document you hand back. Keeping it untouched saves hours of manual matching at bid submission.

What the contractor must fill in

The principle is simple: every line requested must carry a price consistent with your breakdown. A few rules apply almost everywhere.

• Leave no empty line. A blank cell is often treated as an incomplete — therefore irregular — bid.
• A line at zero and an unpriced line do not mean the same thing. If the work is included elsewhere, say so explicitly.
• Variants and options go in the sections provided, never by altering the base bid.
• Clarify what a price covers when the description is ambiguous — it prevents later arguments about scope.

The most common pitfalls

Most rejected bids are rejected on form, not on price.

• Altering the file structure — adding lines, renaming chapters, reordering. The bid becomes incomparable and may be thrown out.
• Overwriting the total formulas by pasting values: subtotals no longer follow.
• Pricing an obviously wrong quantity without flagging it. Better to submit a written question during the tender: the answer benefits every bidder and protects you.
• Reusing a DPGF from a previous job without re-checking codes and units. Templates look alike; quantities never are.
• Returning the file in a format that was not requested, or renamed.

Good practice for working fast

A technical-package DPGF often runs past a thousand lines. Re-keying is therefore not a reasonable option.

• Import rather than re-key. Pulling the structure and codes straight from the tender file removes the main source of error.
• Keep the original codes throughout the estimate: reconciliation becomes automatic at submission.
• Isolate variants and options from the outset, in a separate branch of your estimate.
• Check before sending: unpriced lines, inconsistent units, zero quantities, any gap between your calculated total and the expected total.
• Archive the version you submitted. That is the one that will govern variations.

In short

A DPGF is not just a table to fill in: it is the document that makes your bid readable, comparable and defensible. Distinguish it from the BPU and the DQE, follow the supplied template to the letter, keep the codes, and automate the import rather than the typing. The time saved on mechanics goes back into what actually makes the difference: the accuracy of your prices.