Network Installation Acceptance Tests Before Final Payment

By Yogesh Sagale

The cabling is in, the switches are blinking and the contractor has sent the final invoice. Staff are already working on the new network, so it is tempting to pay and move on. Three months later, a few desks drop their connections, an access point keeps rebooting and nobody can say which outlet goes to which port. Without a dated acceptance record, separating an installation defect from a later change becomes harder. Warranty and contractual obligations may still apply; payment alone does not establish that every fault was waived.

Acceptance testing is how an owner, facility manager or consultant turns “it seems to work” into a documented result that can be checked against the contract. This article explains what to test, what evidence to request and how to judge it, so that final payment is linked to proof rather than appearance. This guide is for office owners, IT managers and facility teams who must decide whether the agreed installation scope has been demonstrated. Our handover guide explains the documents to receive; this article explains how to judge evidence against acceptance criteria. For cable testing methods, see our guide on Fluke testing and Cat6/Cat6A certification. Payment timing and retention follow the signed agreement, not a universal testing rule.

What acceptance testing is, and what it is not

Acceptance testing is a defined set of tests, run against agreed criteria, whose recorded results decide whether the installation is accepted. Three distinctions prevent most disputes:

• Continuity is not certification. A wiremap or continuity check shows that conductors are connected in the right order. A certification test measures the link’s electrical performance against the limits of a named standard and category.
• Nominal speed is not usable throughput. A port that negotiates at 1 Gbps says nothing about what an application will achieve across the network.
• “It works today” is not a test. Intermittent faults, marginal links and PoE shortfalls often appear only under load, at a different time or after several devices are connected.

Define the criteria before the work starts

Acceptance is only fair if the criteria were in the purchase order or contract. If they were not, agree them in writing before testing begins. At minimum, specify:

• The standard and cable category the links must be certified to, including the edition. The edition and the correct test limits should be confirmed against the standards body’s current publication and the tester manufacturer’s documentation.
• Whether 100% of permanent links are tested or only a sample. For a new certified cabling scope, requiring a report for every installed permanent link is a practical procurement recommendation. Sampling cannot certify untested links; agree the requirement rather than adding it after completion.
• The tester model, its calibration status and the firmware or test-limit version used.
• The format of the deliverables: native tester files plus a readable summary, so results can be independently reviewed.
• What happens to a failed link: who repairs it, who retests it and in what time.
• Which services must be demonstrated: internet, VLANs, PoE devices, WiFi, failover, remote access, CCTV or telephony, as applicable to your scope.

The test areas and what to retain

1. Documents and physical inspection

Before any measurement, check what has been installed against what was ordered. Compare the bill of quantities with the equipment, the as-built drawings with the outlet positions, and the labelling with the patch panel. Look at cable routing, support, separation from power cables, termination quality, firestopping of penetrations where applicable and rack layout. Inspection is quick, and it often exposes faults that a tester will never detect.

2. Copper cabling certification

Every permanent link should have a stored report showing the standard and category tested, the result and the measured parameters, with the tester identity and date. Retain the native files, since a PDF summary cannot be re-analysed. Judge the result as follows:

• Pass: accepted, subject to the report showing the correct test limit.
• Fail: rejected until the cause is fixed and the link is retested, with both the original failed result and the dated retest retained. Mark the current accepted result without deleting the repair history.
• PASS* and other uncertainty markers: interpret the exact marker using the tester documentation. Fluke explains that a marginal PASS* remains a standards-compliant pass; the asterisk identifies measurement uncertainty. A client may specify stricter treatment in advance, but should not retrospectively call every PASS* a standards failure. Investigate reproducibility and follow the written acceptance rule. FAIL or FAIL* must not be counted as an accepted pass. [1]

Permanent-link and channel testing are different; confirm which one your criteria specify, and that the correct test adapters were used.

3. Fibre links (if installed)

Fibre acceptance uses the agreed optical loss test set (OLTS) method for end-to-end insertion loss, with connector inspection and cleaning before measurement. Record fibre identity/type, polarity, length, reference method and test-cord verification, launch conditions, wavelengths and directions required by the specification. An OTDR adds event locations and characterisation when specified or needed for troubleshooting; it does not replace the OLTS loss measurement. [2] Compare results with both the agreed installed-cabling limit and the target application’s channel loss and length requirements. See the example below.

4. Switching, VLANs and PoE

Export the switch configuration and confirm VLAN assignments, trunk ports, spanning-tree settings and management access against the design. For PoE, connect the real devices (access points, cameras, phones), then record the total switch PoE draw and each port’s status. The budget method is explained in our PoE power budget guide; for acceptance, check compatible per-port PoE capability, negotiated or reserved allocation, maximum/startup demand and total budget on each switch. Actual typical draw may be lower than power allocated by class or negotiation. Record a controlled all-device power-up/recovery test and any denied-power events; confirm the available budget under the actual power-supply configuration. [5] Also prove VLAN access policy with authorised allowed and denied traffic tests: a configuration export alone does not prove isolation.

5. WiFi

Walk the floor with a survey tool and record signal level, noise, channel use and measured throughput in each area named in the design. Include the places users actually sit, not just corridors. Roaming should be checked by moving between access points during a call or a continuous transfer. Record the actual client model, radio band, channel width, location, occupancy and load during tests. Check retries, packet loss and application behaviour alongside radio measurements. Set targets for the real clients and applications; a generic signal-strength number is not a universal acceptance standard. Cisco’s survey guidance makes client/application context part of coverage validation. [4] If no targets were set, agree them before testing. Placement principles are in our WiFi access point placement guide.

6. Internet, firewall and failover

Measure throughput and latency at more than one time of day, and record the method and tool. Usable application throughput is generally below a nominal interface rate because protocols and the test path add constraints. Compare with the actual ISP service terms and agreed design criteria; a best-effort speed test alone does not prove an SLA breach. Separate wired LAN tests from WAN tests. For a local iperf3 test, record client/server capability, tool versions, direction, duration and stream count, and restrict the test service to authorised hosts. [6] Review the firewall rules, guest isolation, administrator access and default credentials. If two links are installed, perform a controlled primary-link failure and restoration in an agreed maintenance window and record detection time, usable-service recovery, sessions that reconnect or drop, and failback behaviour. Agree what counts as a failure: loss of link and upstream loss of internet may require different health checks. Note that failover design has limits that are covered in our dual ISP guide.

7. Power, rack and environment

Check that the rack is on its intended circuit, that the UPS carries the real equipment load and that its runtime test is recorded against the agreed backup target, and that cooling and clearance meet equipment instructions. Check both watt and VA ratings; do not double-count PoE devices already included in measured switch input watts. Electrical safety verification belongs to the responsible licensed electrical engineer; a network acceptance report does not replace it.

Worked example

An illustrative example with stated assumptions. It is not an installed APYS project, and the figures are not measurements.

Cabling results

Assumptions: an office with 60 copper permanent links, all certified to one named category, with a contractual retention of 10% of the contract value until acceptance.

For this example only, the contract requires unmarked passes after any agreed repair/retest. Assume all five reviewed links then produce valid unmarked passes: 55 + 3 + 2 = 60 accepted links. The ledger must contain 60 unique outlet IDs matched to 60 valid current reports; duplicate IDs or missing reports cannot fill the count. The retention is released after the remaining gates close, not after cabling alone.

Fibre loss budget

Assumptions for a hypothetical multimode test boundary: 150 m at 850 nm, a chosen fibre allowance of 3.5 dB/km, two mated connector pairs at 0.75 dB each, and no splices. The chosen reference/test boundary includes those two pairs; verify what the actual method includes. These coefficients are illustrative only. Real values must come from the standard, the cable data sheet and the connector data sheet you are using.

This calculation is a planning allowance, not proof that an Ethernet application will run. Fluke explains that an application can have a tighter loss requirement and a separate length limit. [3] For example, if a purely hypothetical application-channel limit were 1.800 dB and a comparable channel measurement were 1.900 dB, the channel would miss that application limit by 0.100 dB even though 1.900 is below 2.025. No actual transceiver or certified application is specified here. Include patch cords and connections outside a permanent-link boundary when judging the full channel.

A possible payment structure

The split below is an example of how a contract could tie money to evidence. It is not a market norm, and the percentages should be set in your agreement, under the agreed commercial terms. The example totals 40 + 30 + 20 + 10 = 100%; it is not an instruction to withhold a payment contrary to an existing agreement.

Common failures and how to respond

Investigate from the bottom up: physical link, addressing, name resolution, routing and firewall, then application. Changing several things at once makes the cause harder to find.

A practical witness test sheet

Agree the witnesses and service owners before testing. For each test, record an ID, the asset or outlet, the agreed target, actual result, tool and settings, date/time, witness and disposition. For WiFi and throughput, include client type and load conditions. Sensitive configuration files belong in a restricted handover location; the client-facing summary can reference them without exposing passwords or keys.

These are test-sheet examples, not universal requirements or results. An unresolved critical safety, security or business-service defect should be escalated through the agreed acceptance process. Cosmetic snags may have a different treatment if both parties record the exception. Keep the acceptance decision separate from the fact that a test was witnessed.

Handover and final-payment checklist

• Contract criteria and test standard confirmed in writing
• Bill of quantities reconciled with installed equipment
• As-built drawings and outlet schedule provided
• Native certification files and readable summary for every link
• Fibre test results with the calculated budget (if applicable)
• Labelling verified at both ends against the patch map
• Rack layout, power and UPS runtime records
• Switch and firewall configuration backups handed to the authorised owner
• IP plan, VLAN list and ISP circuit details
• PoE load, WiFi survey and throughput test records
• Failover test record (if two links are installed)
• Equipment list with serial numbers and warranty terms
• Administrator credentials transferred securely, default passwords removed
• Signed snag list, with blockers closed; any agreed nonblocking exceptions have an owner, deadline, payment treatment and warranty responsibility

Must contain: product, licence type, term start and end dates, renewal contact, and the account under which it is registered. Licences registered in the installer's name make the client dependent on that vendor. Registration in the client's name, or a documented transfer procedure, avoids this. Whether any feature stops working when a subscription lapses depends on the vendor, so check each product's documentation.

Must contain: a list of administrative accounts per device and system, with the account owner. Defaults must be changed. The client should hold the master administrative accounts. Record account names, roles, owners and approved recovery methods in the pack. Transfer passwords, MFA recovery material and backup encryption keys using an approved password manager or another controlled method, separately from general project documents. Confirm the client can authenticate; do not reproduce secrets or full configuration exports in a public blog, uncontrolled spreadsheet or routine email. If the installer retains a support account, record its scope and how it is enabled and disabled.

Audit the report ledger, not the file count

A folder containing 60 reports does not necessarily cover 60 installed links. Reconcile the approved outlet schedule against current results by unique link ID, and keep earlier attempts in a separate history view. The following deliberately flawed example shows why a count alone is weak evidence.

This example assumes correct test limits and valid setup for the other 58 records; it makes no claim about an actual installation. An older PASS followed by a valid FAIL on the same unchanged link is a discrepancy to investigate, not permission to select the more favourable file. Resolve link identity, intervening work and test validity, then document the current disposition. A renamed PDF is not a new measurement.

Use one acceptance row per installed link

Copy these fields into the handover ledger: outlet ID; panel position; installed link type; specified category/standard edition; current native report reference; test date; tester and adapter identity; result; repair/retest history; reviewer; disposition. The client should be able to trace a physical outlet to its accepted report without guessing a filename. Interpret uncertainty markers using the manufacturer guidance already cited above.

Separate service blockers from payment decisions

Record each open item as safety/security, critical service, performance, documentation or cosmetic; then apply the severity and acceptance treatment agreed for that project. Classification is a working aid, not a universal payment rule. A witnessed cable test does not approve the firewall policy, restore procedure or Wi-Fi application experience. Link each service gate to its own evidence and approver. Any partial acceptance, retention or exception must follow the agreement and identify the owner, deadline and retest needed for closure.

Frequently asked questions