A useful line item must answer five questions at once: what is it, how many, against which revision, with which evidence and under which commercial state?
A purchase order contains one line: 'aluminium windows, 500 sets'. The drawing register contains 34 types, two finish revisions, alternate glass build-ups, screens on selected elevations and several doors awaiting hardware approval. The deposit is requested against a total that cannot be reconciled to released openings. This is not merely a spreadsheet problem. It is a configuration-control problem with commercial consequences. The solution is a governed line-item schedule linked to the signed document set, not a bigger free-text description.
1. Define what the schedule controls—and what it does not
State the schedule's purpose, status, owner, revision and precedence route. It may be a tender comparison, contract attachment, release register, invoice support or handover index; those are not automatically equivalent. Only the signed documents and their agreed precedence determine obligations. A working schedule should never silently override drawings, specifications or authorised changes.
ISO 10013:2021 provides guidance for developing and maintaining documented information needed for an effective quality management system. Its public scope notes that documented information can support processes and evidence results; it does not mandate a particular hierarchy or spreadsheet. Use that principle here: every row needs identity, revision, owner and traceable evidence so the team can reconstruct what was approved.
Create stable identifiers. A line ID is not the same as an architectural opening mark, product type, shipment package or invoice line. Preserve each relationship explicitly. Do not renumber historical lines to make a current issue look tidy; close or supersede them with a traceable link.
| Control | Required entry | Failure prevented |
|---|---|---|
| Purpose/status | Tender / contract / release / invoice-support / handover and authorised status | Using a draft as an obligation |
| Document identity | Schedule number, revision, issue date and owner | Untraceable spreadsheet copies |
| Baseline links | Contract, drawing, specification and approved-submittal revisions | Rows tied to mixed technical states |
| Precedence/change route | Reference to signed rule and authorised change process | A schedule silently changing the contract |
| Currency/unit conventions | Currency, tax basis if applicable, unit of measure and rounding rule | False arithmetic reconciliation |
| Access/history | Controlled location and retained superseded issues | Loss of decision evidence |
2. Build each row from a minimum viable line-item record
Split rows at the point where a difference can change price, release, evidence, packing, delivery or acceptance. Openings that look similar may require separate lines when glass, finish, hardware, screen, performance, destination, release date or evidence differs. Conversely, do not split identical items into dozens of decorative rows that cannot be reconciled. The aggregation rule should be written and consistently applied.
Describe the configuration through controlled references and a concise discriminating summary. A row can identify opening marks, product/type code, dimensions/status, operation, frame/finish, glass, hardware, screen/accessory state and approved document references. Do not copy uncontrolled technical values from emails into the contract column. Mark unresolved values as holds with an owner and due date.
Keep ordered, released, produced, inspected, packed, shipped, delivered and accepted quantities separate. These are different states, not a single progress percentage. Each movement must point to evidence and date. A factory self-report can support production status but does not by itself prove contractual acceptance or site receipt.
| Field group | Example form (placeholders only) | Control question |
|---|---|---|
| Identity | Line ID; type; opening-mark range | Can the row be mapped to the approved opening schedule? |
| Quantity | Ordered quantity and unit of measure | Is the unit unambiguous and arithmetically reconcilable? |
| Configuration | Drawing/submittal revision plus concise glass, finish, hardware and accessory distinctions | Are commercial and technical baselines aligned? |
| Evidence | Required submittal/test/inspection/document IDs and status | Does the evidence apply to this configuration and scope? |
| Commercial | Unit/line value where authorised; inclusion state; tax/currency convention | Can the sum reproduce the controlled total? |
| Delivery | Shipment lot, named place, package IDs and state | Can the physical units be traced without claiming acceptance? |
| Hold/change | Open issue or authorised change ID | Is unresolved scope prevented from premature release? |
3. Attach an evidence plan by line, lot and decision
ISO 10005:2018 describes guidance for establishing, reviewing, accepting, applying and revising quality plans. A project quality plan can identify which processes, responsibilities and documented information apply to a specific case. Use that logic to define evidence before production: submittal approval, material/finish samples, declared performance documents, test reports, inspection points, packing records and handover documents as actually required by the contract.
Do not assume that one test report covers every row. Record the tested specimen/configuration, issuing body, method/edition, report scope, stated results, limitations and the responsible project's applicability decision. A change in size, glass, hardware, reinforcement or installation can affect applicability. The schedule should show 'evidence received' separately from 'evidence reviewed/accepted under the project route'.
Set inspection and release states without inventing acceptance criteria. ISO 2859-1 describes sampling procedures indexed by acceptance quality limit for lot-by-lot inspection, but a supplier should not choose an AQL, inspection level or acceptance scheme on the buyer's behalf. If a contract uses sampling, identify the agreed edition, lot formation, characteristic, plan, authority and disposition route. Otherwise show the project-approved inspection method rather than borrowing a familiar sampling label.
| Evidence | Applicability fields | Status states |
|---|---|---|
| Approved technical submittal | Lines/opening marks, configuration and revision | Submitted / reviewed / approved / rejected / superseded |
| Test or classification report | Specimen, method/edition, scope, limitations and project decision | Received / applicability open / accepted for stated purpose |
| Inspection record | Lot, characteristics, agreed method and disposition authority | Planned / witnessed / passed / failed / concession open |
| Packing/loading record | Line quantities, package IDs and shipment | Planned / packed / reconciled / discrepancy |
| Delivery/receipt record | Named location, date, quantities and exceptions | In transit / received with exceptions / reconciled |
| Handover document | Language, format, recipient and applicable lines | Draft / issued / accepted under project route |
4. Reconcile totals and changes without rewriting history
Use three independent reconciliations. Quantity: schedule total to opening schedule and authorised changes. Value: line extensions, approved allowances/adjustments and taxes where applicable to the controlled contract total. Physical: released rows to production lots, packages, shipment documents and receipt records. A balanced value does not prove the right configurations were shipped.
For each proposed change, retain the original line and create a controlled disposition: unchanged, revised, split, cancelled or superseded. Link the request, technical assessment, evidence impact, quantity/value/programme proposal, authorisation and effective revision. Do not back-edit the original baseline after a variation, because that removes the audit trail needed to understand payment and delivery.
Use exception reports. Flag negative quantities, duplicate opening marks, missing revisions, unmatched package IDs, released lines with open technical holds, and payment claims exceeding the evidence-backed state. These flags are prompts for review, not automatic allegations of breach.
| Reconciliation | Compare | Exception example |
|---|---|---|
| Quantity/configuration | Contract lines ↔ approved opening schedule ↔ authorised changes | Opening mark appears twice or against different glass |
| Commercial value | Line values ↔ allowances/changes ↔ controlled total | Total balances only because an excluded accessory is omitted |
| Physical/evidence | Released lines ↔ lots/packages ↔ shipment/receipt evidence | Package count exists but unit identities are not mapped |
| Payment basis | Claimed milestone lines ↔ required evidence and authorised certification | Invoice issued before the stated evidence is available |
5. Issue a line-level release, not a blanket 'proceed'
Before procurement or production, classify each line: released for the stated scope; released with an expressly authorised qualification; held; or cancelled/superseded. Identify who authorised the state and when. Never infer release from deposit receipt, drawing transmission or absence of comments unless the signed process expressly provides that result and the authorised parties confirm it.
The schedule should make uncertainty usable. A held line with a named missing decision, owner and deadline is safer than an apparently complete row built from assumptions. At close-out, retain the original baseline, authorised revisions, final line states, evidence index, shipment mapping and unresolved exceptions according to the project's record process.
FAQ
Can one line cover all project windows?
Only if the controlled aggregation rule preserves every difference that affects configuration, value, evidence, release, packing or acceptance. In most mixed schedules, more than one line is needed.
Is the bill of quantities automatically the contract scope?
No. Its status and precedence depend on the signed contract documents. Label the schedule's purpose and authorised status.
Does 'test report received' mean the line is approved?
No. Applicability and project acceptance require separate review against the actual configuration, method, scope and governing requirements.
Should released and produced quantities share one column?
No. Keep each lifecycle state separate and link it to dated evidence.
Can a changed row simply overwrite the old one?
No. Retain the baseline and link the authorised revised, split, cancelled or superseding line so quantity, value and payment remain auditable.
Continue the project review
Connect this guide with the proposed window and door systems, then review how Cavorlen approaches manufacturing and quality control. When your schedule is ready, send it through the project review form.
Official sources used
ISO 10005:2018 — Quality management: guidelines for quality plans ↗ISO 10013:2021 — Guidance for documented information ↗ISO 2859-1:1999 — Sampling procedures for inspection by attributes ↗UNCITRAL — CISG official text and explanatory material ↗Related buyer guides
This guide does not create or interpret a contract, bill of quantities, specification, tax invoice, customs classification, payment entitlement, variation, acceptance, warranty or legal remedy. It does not prescribe Cavorlen products, quantities, prices, lead times, tolerances, test results or capabilities. Project designers, quantity/commercial professionals, authorised parties and legal advisers must approve the actual schedule and its contractual status under the governing documents and law.