Acceptance act for a batch of PCs and servers under a government contract: template

Why you need a complete acceptance package

The acceptance act for a batch of PCs and servers under a government contract is rarely just a single page with signatures. A full package ensures that the acceptance is equally clear to the customer, the supplier and the inspectors, and that the commission’s decision is based on verifiable facts.

The main value of the package is that it covers typical risks: missing line items, omitted cables and accessories, configuration swaps, delivery of defective units or devices with damage. In the public sector this is especially critical: any disputed points should be resolved with documents, not verbal agreements.

Acceptance is usually performed along three directions, and it’s better not to mix them in one paragraph:

• quantity — whether everything was delivered;
• completeness — whether the contents match the specification;
• quality — whether the equipment works and has no defects.

When these parts are separated into attachments and protocols, details are not lost and there are fewer interpretations.

Most often the main act is accompanied by: a registry of serial numbers and inventory data, results of functional tests, a packing list for each unit, and a list of remarks with deadlines for remediation.

Recording serial numbers and test results protects both parties. The customer gains confidence that the equipment on site is the one they paid for. The supplier gets a clear boundary of responsibility: what was handed over, in what condition, and which checks were passed at the time of signing.

Participants in acceptance and their roles

To ensure documents are signed without delays, appoint participants in advance and assign responsibilities. That way questions about serial numbers, tests and completeness are resolved on site rather than through long correspondence.

Typically involved parties are:

• the customer’s commission — reconciles the actual delivery with the contract and specification, records results, makes decisions;
• the customer’s IT department — performs or oversees functional checks and verifies configurations;
• the person responsible for material assets (MOL) or the warehouse — accepts equipment into storage and accounting, checks packaging, seals and completeness;
• the supplier’s representative — provides documents, assists with inventory data (BIOS/UEFI), and coordinates replacements/repairs.

Acceptance can take place at the warehouse (quantity, external condition, seals), in the IT department (functional checks), and in operations (if equipment is put into service right away). Decide in advance whether this will be a one-day event or two stages.

How to agree in advance

Before delivery, agree on the form templates and deadlines: which attachments will be included with the act, who fills the serial number registry, how much time is allowed for tests, and who is authorized to sign final documents.

If the supplier is both the manufacturer and integrator, it’s useful to determine a contact person for service interactions during acceptance. For example, GSE.kz (gse.kz) has local production in Kazakhstan and round-the-clock technical support with a service network across the country — this helps close minor issues faster so acceptance isn’t stalled.

Contents of the package: which protocols and attachments to include

To prevent the acceptance from turning into a dispute about “what exactly was accepted and in what form,” define the document set in advance. It’s practical to make one main act and put details into numbered attachments with clear row and page numbering.

Basic document set

Usually 4–6 attachments are sufficient to answer three questions: what was delivered, in what condition, and what to do if there are non-conformities.

1. Main acceptance act: date and place, contract details, commission composition, outcome (accepted/accepted with remarks/not accepted), list of attachments.

2. Serial number registry: for each device (PC, server, all-in-one) and, if necessary, for key components (e.g., drives), to simplify later accounting and warranty claims.

3. Functional test protocol: brief (minimal set of tests) and, if needed, extended (test conditions and detailed results).

4. Packing list / completeness statement: what’s in the box, what is delivered separately (cables, fasteners, documents), marked as “present/absent”.

5. Remarks and remediation plan: description of the problem, quantity of affected units, deadline, responsible parties and method of verification.

How to make attachments "tamper-proof"

Each attachment should have a number, date and signatures (or approvals if that is the customer’s practice). In the main act indicate the exact number of pages in each attachment so nothing can be added after signing.

If the commission accepts, for example, 20 PCs and 2 servers, record in the registry not only serial numbers but also inventory tags (if they are applied immediately). In the packing list separately note items that may be shipped outside the box: rack rails, cable management, fasteners. This makes comparing with the delivery note and specification easier.

Serial number registry: how to format it correctly

The serial number registry is the primary way to prove that the units accepted under the contract are exactly those delivered. A good registry saves time: it makes it easy to find a device on site, check warranty and close disputes without weeks of correspondence.

It’s convenient to keep the registry as a table and group rows by equipment type. The commission needs to see what the item is, where it will be installed and how it will be recorded.

A minimal set of columns usually includes:

• type/category (PC, monitor, server, etc.);
• model/name;
• serial number (S/N);
• inventory number (if assigned at acceptance) or a note “to be assigned later”;
• installation location (building, room/rack, department).

Do not mix components in one row. For a server, it’s common to have a separate row for the server itself and additional rows for disks, power units, rails (if important for completeness or accounting). This makes reconciliation with the delivery note and specification easier.

Record discrepancies directly in the registry using “status” and “comment” fields. Typical statuses: missing, duplicate, unreadable sticker, model mismatch.

Photographic evidence is appropriate when there is a risk of dispute or weak labeling. Photograph so the serial sticker and the device’s overall appearance are legible; if necessary, include the packaging with markings. In the registry it’s enough to note that a photo exists and the photo date, without embedding images into the act.

Functional checks: what to test and how to record results

Functional checks are needed so that documents contain facts, not impressions: what was tested, under which conditions and with what result. Disputes are resolved faster with clear records.

Minimal test set

For a batch, basic checks that confirm device startup and operation of key subsystems are usually sufficient.

For PCs you typically check: power-on and BIOS/UEFI boot, detection of the drive, network operation (link and IP acquisition), main ports (USB, video), and basic OS or service image boot (if provided).

For servers you usually record: POST without errors, visibility of drives and controller, correct RAID assembly (if supplied), network port checks, access to remote management (if included in the configuration).

If you use a test USB or corporate image, note the conditions in the protocol: date and place of the check, full name and position of the responsible person, device serial number, image/OS version and a short scenario (for example, “boot to service environment, SMART/RAID check, network test”).

How to record results unambiguously

A PASS/FAIL format is convenient, but it should be accompanied by a concrete explanation. Instead of “doesn’t work” record the symptom and context.

Examples:

• "FAIL: LAN1 port, link does not come up when connected to the switch; cable and switch port were verified on another device."
• "FAIL: RAID1 will not assemble; controller sees only one drive, the second is not detected."

Choose the depth of testing based on risk. Full testing is appropriate for small batches, critical servers, new models and when the contract has strict requirements. For large deliveries of standard PCs, it’s often sufficient to verify power-on and identification for all units and perform extended tests on a pre-agreed sample (with a described percentage and selection method).

Checking completeness and external condition

Completeness and external condition are more logically checked before powering on the equipment. This way you quickly see what arrived and do not confuse packaging issues with test results.

How to record completeness

Describe completeness in simple items that any commission member can repeat. It’s convenient to use three statuses: “in package”, “delivered separately”, “not provided by contract”.

Then reconcile with the technical specification: model, key characteristics, quantity. For PCs and all-in-ones separately note power cords, peripherals (keyboard/mouse if provided), documentation, media with software (if included), warranty documents and adapters. For servers add rack mounting hardware, rails/guides (if included), cables and license documents (if applicable).

If a batch contains different build configurations, check completeness by configuration groups rather than one line for the entire delivery.

External inspection

Record packaging and seal conditions separately: integrity, signs of opening, matching of box markings with the device. For the chassis, note specific defects and their location:

• dents, cracks, chips;
• scratches and scuffs;
• damaged ports and connectors;
• missing dust covers or screws;
• signs of moisture or contamination.

If there are discrepancies or damage, do not leave them “verbally.” Tie each remark to a specific unit by serial number.

Acceptance procedure: step-by-step

A consistent acceptance scenario reduces errors and speeds up paperwork.

1. Physical receipt of the cargo: number of packages, integrity of packaging, signs of impact or moisture. Take photos if necessary for the acceptance records.

2. Reconcile documents and labeling: match delivery notes, specification and nameplates on chassis.

3. Check serial numbers: enter data into the registry for each unit, note discrepancies and unreadable markings.

4. Functional checks: prepare the test area (power, network, monitor/keyboard, boot media or standard image). Record the scope of testing (all units or sample) and test conditions.

5. Remarks and remediation plan: create a list of remarks with wording, deadlines and responsible parties. After remediation, perform a repeat check on disputed items and record the result.

What to sign and in which order

To keep the package intact, usually sign the main act and immediately attach its appendices: the serial number registry, test protocol(s), and the packing list. If there are discrepancies, add a remarks sheet with deadlines and the procedure for re-inspection.

If remarks are critical (affect commissioning), it’s better to sign the act with a reservation and an attached remarks sheet than to leave the issue verbally unresolved.

Remarks and remediation: how to record without disputes

Disputes often arise not from the defect itself but from how it was recorded. State a remark as a verifiable fact: what was found, where and when, on which device, how it was confirmed, and what impact it has.

Example: “PC L200, S/N KZL200-001234, room 312, on power-up SMART error appears (photo of the screen dated 12.01.2026), OS cannot boot.” Here we have the device, the symptom and why it matters.

Categories of remarks

To avoid arguments, it’s useful to agree in advance on two levels:

• critical — cannot be accepted (does not work, fails tests, contradicts the specification, mandatory components missing);
• non-critical — can be accepted conditionally (cosmetic defect without seal violations, secondary accessory missing, configuration/update needed without loss of functionality).

If you accept conditionally, record directly in the act: the list of remarks, remediation deadline and what counts as confirmation (replacement, additional components, repeat test, engineer visit, protocol).

Deadlines, re-acceptance and closure

Assign a supplier contact responsible for each remark and a customer contact. Record the remediation action specifically: “replacement with a new device with new S/N,” “repair retaining the S/N,” “additional components: 1 power cable,” “BIOS/firmware update with repeat test.”

Re-acceptance is formalized with a short document: “Act of remediation” or an attachment to the original act. Cite the original document, list closed items, new serial numbers (if replacements occurred) and the outcome: “remarks resolved, no claims remain.”

Common mistakes during acceptance and how to avoid them

Many disputes in government contracts arise not from equipment but from documentation. Frequent issues include:

• the registry lacks serial numbers or they don’t match stickers on chassis and BIOS/UEFI data (check in at least two places and note who verified it);
• test protocols contain vague phrases like “works normally” without conditions and results (include date, scenario and outcome);
• different models and configurations are mixed in one table making it unclear what was delivered (separate by model and provide totals for each group);
• signatures are from unauthorized persons, missing printed names, dates, or stamps where required (verify powers of attorney and commission orders in advance);
• small completeness items are not checked: power cords, adapters, rack rails, fasteners, documentation (a simple checklist with “present/absent” helps).

Practical example: a commission accepted 20 PCs, but a week later accounting could not register them because the registry included serial numbers only for the chassis, not for the monitors. An additional document package and re-gathering of signatures were required. This is easily avoided by keeping separate rows for each item and checking labeling on site.

A working rule: if an item cannot be checked “by sight and touch” or with a simple test, it must be confirmed by a measurable result or a specific attachment to the act (registry, protocol, packing list).

Pre-signing checklist

Perform a final reconciliation before signing. It takes 10–20 minutes but often saves weeks of repeated coordination.

1. Compare delivery documents with the contract specification: names, models, configurations, quantities, units of measure.

2. Verify that:

• the batch matches the specification (including monitors, rails and other items if provided);
• the serial number registry is filled without gaps or typos and the test scope (all units or sample) is recorded;
• the functional test protocol is completed and signed (what was tested, how many units, results);
• completeness and external condition were checked for each position and notes were made according to the adopted procedure;
• all remarks are recorded on a separate sheet with date, responsible parties, deadline and confirmation method.

If there are discrepancies, do not blur them with vague wording like “accept with deficiencies.” Better to sign the act with attached remarks and a clear remediation plan.

Realistic example and next steps

Delivery: 50 PCs and 2 servers to a government institution. The goal is to accept without disputes in 1–2 days so accounting and IT can close the contract and the supplier can receive payment on time.

Agree the acceptance window a day before arrival (for example, 10:00–17:00) and prepare printed and electronic tables. Practically, it’s useful when the supplier brings templates and they are filled on site: the MOL handles documentary parts and quantities, the IT specialist performs checks.

Minimum pre-prepared documents: serial number registry, functional test protocol, packing list and remarks sheet with deadlines.

On site, acceptance can be split: one person checks delivery notes and serial numbers on boxes and chassis, another performs selective functional tests (e.g., 10 out of 50 PCs plus both servers).

Scenario: 3 devices have serial numbers that don’t match the registry. Do not sign the package “without remarks.” Isolate these 3 units, record the discrepancy (in a separate sheet/act), photograph the nameplate and note where the discrepancy was found (box, chassis, BIOS/UEFI). A common cause is a typo in the registry or swapped boxes.

Partial acceptance is straightforward: the main act is signed for the actually accepted units, while disputed items are recorded in a discrepancy act with an obligation to replace/fix. After remediation — a short re-check and an attachment confirming closure of remarks.

To make the next delivery smoother, request the manufacturer’s serial number registry and protocol templates that match your act format in advance. If GSE supplies the PCs and servers, you can pre-agree on document formats and the service interaction procedure during acceptance.