Equipment Kit Return Checker

What the return check tells you

• A frozen manifest defines the loan, version and expected return count for each component.
• Required, optional and consumable are explicit expectations, not guesses based on an item name.
• Later receipts add to earlier valid receipts; a new arrival needs a new receipt ID.
• Every duplicate receipt ID is excluded, including a previously counted row, until you investigate outside this session.
• Unknown IDs, mismatched loans or versions and malformed rows are retained in the receipt audit or original source batches, with excluded records identified in the report.
• A matched quantity is not evidence of good condition, safe operation, borrower liability or an accepted and closed loan.

How to use the checker

1. Replace the synthetic example with your loan ID, manifest version and component list. Use stable, case-sensitive IDs: CAM-01 and cam-01 are different components. Do not put borrower names, contact details or other personal data into this tool.
2. Set a nonnegative integer expected return count on every line. An optional cable with an expectation of one remains visible if it is absent. A consumable set to zero has no outstanding return quantity; a consumable set to one does. The label never silently changes the count.
3. Choose the receiving policy that applies to your operation, then freeze the manifest. A bad manifest cannot be frozen. Review every reported error and correct the draft first.
4. Append receipts using the exact CSV header, the frozen loan and version, a unique receipt ID, the actual receipt timestamp in UTC and a positive integer quantity. Only record items you physically received. An offered kit that staff refused is not an actual receipt.
5. Check component totals and the receipt audit. Investigate unknown IDs, extra quantities and excluded rows before relying on the comparison. Save the complete CSV or human-readable text report before leaving.

Each input needs its header. CSV fields containing a comma, quote or line break must be quoted, with embedded quotes doubled. Internal blank lines are invalid rows, not ignored separators. The tool does not convert ID case, trim identity fields or invent missing timestamps.

Worked example: the second battery arrives later

The prefilled DEMO-LOAN-01 manifest, version v1, expects one camera body and two rechargeable batteries as required components. It also expects one optional spare cable and one unused sealed battery pack classified as consumable for this example. The tape roll has an explicit consumable return expectation of zero. These are synthetic records, not a recommended policy for those items.

Freeze the sample and append its first receipt batch. The camera is matched. One required battery is missing; the optional cable and the unused sealed battery pack expectation remain outstanding. The tape has nothing outstanding because its expected return count is zero.

To record the later battery, append the header followed by the row below. Its different receipt ID adds one battery to the earlier receipt, matching the required battery count without changing the original manifest or receipts.

receiptID,timestamp,loanID,manifestVersion,componentID,quantity
RCPT-003,2026-10-19T14:00:00Z,DEMO-LOAN-01,v1,BAT-01,1

The optional cable and consumable unused sealed battery pack expectation are still outstanding. Adding another camera would flag an over-receipt, not cancel out a missing accessory. Pasting RCPT-002 again would exclude both rows with that ID, not count the same receipt twice.

Partial return policies are not interchangeable

Loyola University Chicago’s check-in policy permits returning separate complete kits at different times, but requires the associated items within each kit to return together. That is not permission to return an incomplete kit.

UW Bothell’s circulating equipment agreement says a return with missing components is recorded as a partial return and remains an active loan until all components are received. Its policy may also restrict borrowing privileges.

Sources checked October 19, 2026. These are institution-specific examples, not universal rules or advice about your agreement. The policy selector documents your chosen approach; it never automatically accepts equipment, ends liability or closes a loan. Actual receipt, acceptance and closure are separate decisions.

Keep dispatch, receipt and inspection separate

A pull sheet checks what leaves for a job. A return manifest checks what should come back on one loan. Use the AV equipment pull sheet template for pulled, checked, staged and loaded quantities; use this checker for component-level receipts against the agreed return expectations.

If submissions arrive through forms, the equipment checkout with Google Forms guide explains matching loan records in a coordinator-controlled ledger. A submitted form is not proof of physical receipt. Investigate exceptions before transcribing the verified receipts here.

Quantity reconciliation cannot inspect damage, test a battery or certify that a kit is ready for the next booking. Keep your condition checks and authorized acceptance or closure decisions in the system your team uses. More workflows are in the equipment checkout hub and templates and tools hub.

Who this fits — and where it stops

Use this tool for a small equipment desk, AV team or lending operation that already knows the loan manifest and needs a transparent return-count comparison. It fits one coordinator reconciling one loan version at a time.

It does not fit teams needing shared live records, authentication, an audit-grade permanent ledger, automatic acceptance or inspection sign-off. There is no saved account history or report re-import. Invalid appended records cannot be edited: export the evidence, investigate, then start a new session with verified source data if correction is necessary. Changing the expected manifest requires a new version and clears prior receipts; export first. This page blocks reuse of a previously frozen loan ID and version only while it remains open. Refreshing or leaving clears that version history as well as the inputs; it is not a permanent version registry.