Author: Nithish

An asset tagging sample is a worked example showing how a single serialised item, such as a two-way radio or CCTV unit, is recorded from the day it enters a security company’s system to the day it is retired, including the fields that change at each stage: onboarding, location, custodian, transfer, stocktake and retirement.

Most explanations of asset tagging describe the idea in the abstract. What is harder to find is a concrete example: one real asset, followed stage by stage, showing exactly what gets recorded and when. That is what this guide walks through.

Why a worked example matters more than a definition

Knowing that asset tagging gives an item a unique ID is one thing. Knowing what that ID actually tracks and when the record is supposed to change is another.

Most mismatches between a tagging system and reality happen at the transitions: the moment an asset moves site, changes hands or goes for repair. A definition will not show you what a transfer record looks like partway through approval, or what a stocktake flags when an item cannot be found. A good asset tagging sample will.

The asset tagging sample: one radio, tag to retirement

This asset tagging sample follows a single asset through six real stages, using the asset-code prefix, transfer workflow, custodian field and stocktake process a security company’s assets module actually runs on.

The asset: a two-way radio, asset code RAD-00231, issued to AVES Protective Services’ Riverside Mall site.

Stage	What happens	Field or record updated
1. Onboarding	The radio is received into the system under the organisation’s RAD- asset-code prefix and given a unique ID.	Asset ID created, type and description logged
2. Location placement	The radio is assigned to Riverside Mall as its home site.	Location field set
3. Custodian assignment	The radio is handed to a named guard for the shift.	Custodian field set to that guard
4. Transfer	The site needs an extra radio at a second location. A transfer is requested, authorised by a supervisor and confirmed received at the new site.	Transfer logged: requested, authorised, confirmed; location field updated
5. Stocktake	At the next scheduled stocktake, the radio is scanned on site and reconciled against the system record, with no mismatch found.	Stocktake entry added, status confirmed
6. Defect and retirement	Months later the radio develops a fault. It is flagged as defective, then moved to under-repair status. After repeated failures it is retired.	Status changed to defective, then retired; history trail kept

Every row above changes a field on the same asset record, not a fresh entry. That is the point of tagging: one scannable ID carries the full history, rather than six disconnected notes in six different places.

That matters beyond the shift itself. When a client or an insurer later asks where RAD-00231 was on a given date, the full six-stage history can be exported from the one record rather than reconstructed from six separate logs. The same applies when an internal audit needs every asset that passed through a particular site.

What a good asset tagging sample should always show

A genuine asset tagging sample, not just a definition, should demonstrate:

• A unique asset ID tied to one physical item for its whole working life
• An onboarding step that assigns the ID and basic details at the point the asset is received
• A location field that updates whenever the asset moves site
• A named custodian, not just “the site” or “the team”
• A transfer step with request, authorisation and confirmation, not a single tap
• A stocktake that reconciles the system record against what is actually scanned
• A status field that reflects defects and retirement without deleting the asset’s history

Common mistakes a worked example exposes

Walking through a real asset tagging sample also exposes the mistakes a bare definition hides:

Treating the ID as the whole record. The asset code is just the key. The value is in what gets updated against it: location, custodian, status, each time something changes.

Skipping the authorise step on a transfer. A transfer that only records “requested” and “confirmed” with nothing in between loses the approval trail a dispute would need.

Letting custodian go stale. If the custodian field is only set once, at onboarding, it stops reflecting who actually has the asset after the first shift change.

Treating a stocktake as a one-off. A single stocktake catches mismatches that already happened. A scheduled one catches them early, before an item is genuinely lost.

Deleting a retired asset. Retirement should change the status, not remove the record. Deleting it erases the exact history a later audit would need.

FAQ

Is an asset tagging sample the same as an asset tagging template?
They overlap. A template is usually a blank table of the fields to track. A sample, like the one above, shows those same fields filled in and changing across a real sequence of events.

How many stages does a typical asset go through?
It depends on the item. A radio or camera that moves between sites will usually pass through onboarding, location, custodian, transfer and stocktake stages several times before an eventual retirement. The six stages above are the complete set, not a fixed count per asset.

What happens to the record once an asset is retired?
The record’s status changes to retired, but the history is not deleted. Keeping the trail intact is what lets a later audit confirm where the item was and who held it, right up to the point it was taken out of service.

Does every asset need a transfer record?
Only assets that move between sites or custodians. An item that stays at one location with one custodian for its whole life will show onboarding, custodian and stocktake entries, but no transfer.

Can a lost asset reappear in the record?
Yes. If a stocktake cannot locate an item, it is flagged, not deleted. If it is later found, the same record is updated rather than re-created, keeping one continuous history.

How this looks inside AVES

AVES’s asset tagging software runs the six-stage pattern above as a working system rather than a worked example: onboarding through the receive endpoint with an organisation’s own asset-code prefix, location placement, custodian assign and release, transfers that move through request, authorise and confirm or reject, scan-to-reconcile stocktakes and status changes through to retirement, all kept on a single asset history trail. For how the four tagging methods behind the ID itself compare, see what is asset tagging.

An asset tagging sample tracks operational history; it is distinct from the fixed asset register, which is the financial view of what a company owns and from the asset handover form, which logs a single handover event rather than a full lifecycle. The same discipline, tagging and logging every change rather than trusting memory, is also how AVES records daily guard activity in the security guard logbook.

If your business issues serialised equipment across more than one site, book a 30-minute demo and we will show you the asset tagging sample behind this exact example, onboarding, transfer and stocktake included.

Book a demo or start a free trial.

Follow AVES on Instagram for more security operations guidance.

Author: Nithish, AVES Security content team. Last updated: 14 October 2026.

A visitor badge template is the set of fields a site prints or displays on every temporary pass it issues, covering who the visitor is, who they are seeing, which areas they can enter and when the badge stops working. A badge with the wrong fields looks official but proves nothing if it is ever questioned.

Most sites already hand out some kind of visitor badge. Far fewer have actually decided what belongs on it. A sticker with just a name and today’s date looks fine at the front desk, but it cannot answer the questions that matter later: which zones was this person cleared for, who approved the visit and is the badge even still valid.

This guide covers the eight fields a visitor badge template needs, the mistakes that turn a badge into decoration instead of a control and how AVES issues and verifies badges without a stack of paper at the desk.

Why a visitor badge template matters

A badge is the one thing every other person on site sees. If it only shows a name, nobody else can tell at a glance whether this visitor is cleared for the warehouse floor or just the lobby, or whether the badge was issued an hour ago or three days ago. The fields on the badge are what turn it from a sticker into something a guard, an employee or another visitor can actually rely on.

It also matters after the fact. If a badge is found somewhere it should not be, or a visitor is challenged and cannot produce one, the fields on the template decide how fast that gets resolved. A badge with a visible expiry and a scannable ID gets checked in seconds. One with just a name does not.

How AVES issues and verifies a visitor badge

AVES builds the badge from its Security Pass module rather than a printed pad. A visit starts with an access pass request that goes through an approval step, so a badge only exists once someone with the authority to grant it has signed off. The pass carries the visitor’s ID and profile photo, captured at issue rather than copied from an old file.

Each pass also carries a QR code. A guard at any checkpoint can scan it to pull up the record instantly, including who approved the visit and when the pass expires, instead of trusting whatever is printed on the badge itself. AVES also supports admin-configured colour sets for passes, so a site can assign a visible colour per visitor type or zone and know at a glance which badges belong where, on top of whatever the QR scan confirms.

The 8 fields a visitor badge template needs

These are the fields that keep a visitor badge template useful rather than decorative.

1. Full name. Printed large enough to read from a few metres away, not just on file somewhere behind the desk.
2. Photo. A face match a guard can check against the person wearing the badge, captured at issue rather than reused.
3. Host or reason for visit. Who they are on site to see, so a challenge at any point has an immediate answer.
4. Zone or colour. Which areas the badge is cleared for, visible at a glance without needing to ask.
5. Badge ID or QR code. Something a guard can scan at any checkpoint to pull the full record, not just read off the badge.
6. Approval status. Who signed the visit off, so a badge in circulation always traces back to an approver.
7. Valid until. A clear expiry, not an open-ended pass that is still technically live a week later.
8. Issue date and time. When it was handed out, which is what makes a badge found later easy to place.

A visitor badge template built around those eight fields answers the three questions that actually get asked: who is this, where are they allowed and is the badge still good.

Common mistakes that make a visitor badge useless

The most common mistake is no expiry on the badge. Without one, a badge from last month looks exactly like a badge from this morning, and nobody at a glance can tell which is which.

The second is no photo. A badge with a name but no face match can be handed to anyone, which defeats the point of issuing it to one specific visitor in the first place.

The third is a badge nobody can scan or verify. If the only way to check a badge is to trust what is printed on it, a guard has no way to catch a badge that was never actually approved.

The fourth is treating every visitor the same. A contractor heading to a plant room and a guest heading to reception need different zone clearance, and a template with no colour or zone field cannot show the difference.

How AVES supports this, honestly

AVES does not print physical badges itself. What it does is manage the pass behind the badge: the approval step, the ID and profile photo capture, the QR code and the admin-configured colour set that a site prints or displays as the badge. Scanning the QR at a checkpoint always shows the live record rather than whatever is printed, which is what keeps an expired or unapproved badge from being trusted on sight.

There is no automatic door-lock integration tied to badge colour in AVES; zone clearance is something a guard checks against the badge and the scanned record, not something the badge itself enforces at a locked door. Sites that need that level of physical access control should treat the badge as the verification layer, not the lock.

FAQ

What is a visitor badge template?

It is the set of fields a site prints or displays on every visitor badge it issues, covering who the visitor is, who they are seeing, which areas they are cleared for and when the badge expires.

What fields should a visitor badge include?

Eight cover most sites: full name, photo, host or reason for visit, zone or colour, badge ID or QR code, approval status, valid until and issue date and time. Fewer than that and a badge usually cannot answer a challenge on its own.

Does a visitor badge need a photo?

Yes, for any site that wants the badge to mean something. Without a photo, a badge issued to one visitor can be worn by anyone, which removes the point of issuing it in the first place.

How is a visitor badge different from a visitor sign in sheet?

A sign in sheet is the record of who came and went. A badge is what that visitor wears while they are on site, so the two work together rather than replacing each other.

Does AVES support colour-coded visitor badges?

Yes. AVES supports admin-configured colour sets for passes, so a site can assign a colour per visitor type or zone and tell badges apart at a glance, alongside the QR scan that confirms the full record.

Related reading

• Visitor Management System: how AVES manages visitor access end to end
• Visitor Sign In Sheet: 7 columns your template needs
• Visitor Log Book: 10 essential fields to record
• Gate Pass Format
• Security Incident Log Template: 8 columns to include

See it in action

Book a 30-minute demo and we will show you how AVES issues, scans and verifies a visitor pass end to end. Book a demo or start a free trial.

Internal links: Visitor Management System · Visitor Sign In Sheet · Visitor Log Book · Gate Pass Format · Security Incident Log Template (Incident Management hub). External: AVES on Instagram (DoFollow).

Guard tour app: the mobile application a security guard uses during a patrol round to scan QR checkpoints, confirm GPS location, capture a selfie where required and record how long each stretch of the round took. It replaces a paper patrol sheet or a radio check-in with a timestamped, location-verified log a supervisor can check in real time.

Why a radio check-in is not proof of a patrol

“Did the round” and “can prove the round happened” are two different things. A guard who calls in from the gatehouse at the top of every hour has technically checked in, but a phone call carries no evidence of where the guard actually was. For a security company that has to answer to a client, an insurer or a court after something goes wrong, that gap matters.

A security patrol report already covers what a completed round needs to record. A guard tour app is the tool that captures that record automatically, on the guard’s own phone, while the round is happening, rather than reconstructed from memory afterwards.

Why it matters

Unverifiable patrols cost more than they save. Clients pay for coverage, not for a guard’s word that coverage happened. When a checkpoint is skipped, missed or rushed and nobody can show otherwise, the dispute becomes a matter of trust rather than data and trust is a weak position to argue from. A guard tour app turns “we patrolled the site” into a checkpoint-by-checkpoint, GPS-stamped record that either backs the claim or flags the gap before it becomes an incident.

How a guard tour app works on the phone

Strip away the marketing language and a guard tour app does five concrete things during a round:

1. Start the round

The guard opens the app, selects the date and shift and starts the round. Patrol status moves to in progress, so a supervisor watching the dashboard can see a round is underway before the first checkpoint is even scanned.

2. Scan the checkpoint QR code

At each stop, the guard scans a QR code fixed to that location. The scanned code ties the entry to that exact checkpoint, there is no way to log “checkpoint 4” from a QR code that lives at checkpoint 1.

3. GPS verifies the guard was actually there

Alongside the QR scan, the app records the phone’s GPS location at the moment of the scan. This is the step that separates a genuine tour from a guard scanning every code from a chair in the break room: the location data has to match the checkpoint, not just the code.

4. Selfie capture where the checkpoint demands it

For higher-risk or higher-value checkpoints, the app can require a selfie at the point of scanning. This adds an identity check on top of the location check, useful for checkpoints where “someone scanned this” is not a strong enough guarantee that the assigned guard did.

5. Waypoint timing and distance covered

The app logs a start and end time for each waypoint stretch and totals the distance covered across the round. A checkpoint reached in four seconds flat or a round that covers a fraction of the expected distance, is visible in the data rather than buried in a paper log nobody re-reads.

Every checkpoint visited through the round builds into a single record: status, GPS location and scan time, per checkpoint, for the full patrol.

Guard tour app checklist

Before you judge a guard tour app on its marketing page, check whether it actually does the following:

• Captures GPS location against every checkpoint scan, not just at login
• Ties each scan to a specific QR-coded checkpoint, so entries cannot be logged out of place
• Can require a selfie at selected checkpoints, configurable by site risk
• Records a status for every checkpoint in the round, not only the ones completed
• Logs start and end time per waypoint and totals distance covered for the round
• Gives a supervisor a live view of patrol status while the round is in progress

If an app cannot show GPS data per checkpoint, it is a scanning app, not a verification tool.

Common mistakes with guard tour apps

• Treating “app installed” as “patrol verified.” An app on a guard’s phone proves nothing by itself, the GPS and checkpoint data per round is what proves the patrol.
• Leaving selfieRequired off everywhere. Turning on the selfie check only for the handful of checkpoints that genuinely need an identity guarantee keeps the process fast without losing the control where it counts.
• Ignoring the timing data until something goes wrong. Waypoint time and distance covered are useful every shift, not just in an investigation, reviewing them regularly catches rushed rounds before they become a pattern.
• Relying on a radio check-in as a backup record. A verbal check-in has no location data behind it; it should supplement the app record, not replace it.

Guard tour app vs guard tour system

The two terms get used interchangeably, but they describe different layers. The app is the tool on the guard’s phone that scans checkpoints and captures the data. The guard tour system is the full platform: the app plus the supervisor dashboard, the stored records and the reporting that turns individual rounds into evidence a client or a court will accept. A guard tour app without the system behind it is just a scanner; the system is what makes the data usable afterwards.

Frequently asked questions

What is a guard tour app?

A guard tour app is the mobile application a security guard uses during a patrol to scan QR checkpoints, have GPS confirm their location, capture a selfie where required and log the time and distance covered for the round.

How does a guard tour app prove a patrol actually happened?

By recording GPS location against each QR checkpoint scan, with a timestamp. A round that shows the right checkpoints, in the right place, at plausible intervals, is verifiable in a way a paper sheet or a radio call-in is not.

Does a guard tour app need a selfie at every checkpoint?

No. Selfie capture is best reserved for higher-risk or higher-value checkpoints, configured per site. Requiring it everywhere slows the round down without adding much beyond what GPS and QR data already confirm.

What is the difference between a guard tour app and a guard tour system?

The app is the phone-side tool a guard uses on patrol. The guard tour system is the wider platform (app, supervisor dashboard and stored records) that turns the app’s data into a usable, reportable record over time.

What should I check before a round, not just during it?

A security guard logbook entry at shift start, alongside the round itself, gives a fuller record of what the guard observed beyond the checkpoints and if anything needs escalating during the round, it should feed into the same incident report form process rather than a separate note.

What happens if a checkpoint gets missed?

A missed checkpoint should show up in the round data as a gap, not a silent absence. See how AVES verifies a missed patrol against the expected route.

For more patrol and compliance tips, follow AVES on Instagram.

See the app in action

AVES includes a guard tour app with QR checkpoint scanning, GPS verification, configurable selfie capture and waypoint timing built in, alongside the supervisor dashboard that turns every round into a reportable record. Book a 30-minute demo and we’ll show you the checkpoint screen a guard actually uses on a round. Prefer to look around first? Start a free trial.

Credit note template (AEO definition): a credit note template is the fixed layout used to correct a previously issued invoice, showing which invoice it reverses, the amount and tax being reversed and the reason, so an overbilled client sees a clean adjustment instead of a second confusing invoice.

The problem with correcting an invoice after the fact

Security billing has more correction points than most: a site reports fewer guard-hours after the invoice goes out, a client disputes an overtime charge or a contract rate changes mid-cycle. Fixing this by editing the original invoice or issuing a second invoice for the difference leaves no clean record of what was corrected and why.

Clients notice. An adjustment that shows up as an unexplained second charge, instead of a credit note that clearly references the original invoice, is what turns a routine correction into a payment dispute.

Why it matters

A credit note is a tax document, not just a courtesy adjustment. If the original invoice included tax, the credit note needs to reverse that tax correctly, not just the headline amount. Get this wrong and the books do not reconcile even after the client is satisfied.

This is why a credit note template cannot be a free-text note. A client who disputes three separate overtime charges across a billing cycle needs each one resolved with its own reference back to the original invoice, so the collections team is never left guessing which credit covers which charge. A consistent credit note template keeps that reference, reason and tax treatment identical every time, whether the correction is for a single disputed shift or a contract rate applied retroactively across a full cycle.

It also matters for the collections side of the business: an outstanding balance that is actually a billing error, not a late payment, should be resolved with a credit note, not chased through the same dunning process as a genuinely overdue invoice.

How it works in AVES

AVES treats a credit note as its own record type inside the Finance module, not a manual edit to an invoice. The credit note template follows the same draft, issued and applied stages every time, so the fields below are never optional:

• Draft stage lets the correction be prepared and checked against the original invoice before it affects any client-facing total.
• Issued stage sends the credit note to the client, referencing the specific invoice it adjusts.
• Applied stage sets where the credit lands, against the same invoice, a future invoice or an outstanding balance.
• Tax reversal runs through the same tax profile used on the original invoice, so the adjustment is correct, not just approximate.

Because the credit note always references the original invoice number, the collections record and the accounts receivable aging report both show a clean adjustment rather than an unexplained balance change.

What a credit note template must include

1. Reference to the original invoice: the invoice number and date the credit note is correcting.
2. Reason for the credit: a short, specific reason (hours disputed, rate correction, service shortfall) rather than a generic “adjustment”.
3. Amount and tax reversed: both the headline figure and the tax component, calculated against the same tax profile as the original invoice.
4. Status: draft, issued or applied, so everyone can see where the correction stands.
5. Where it is applied: the specific invoice, future invoice or outstanding balance the credit offsets.
6. Approval trail: who issued the credit note, since a credit note changes what a client owes and should not be a one-person action with no record. A credit note template that skips this field leaves no way to confirm who authorised the adjustment.

Common mistakes

• Editing the original invoice instead of issuing a credit note. This destroys the audit trail of what the client was originally billed and why it changed.
• Forgetting the tax reversal. A credit note that only reverses the headline amount leaves the tax component unreconciled.
• Leaving the reason vague. “Adjustment” tells a client nothing; a specific reason prevents the same dispute coming back next cycle.
• Chasing a billing-error balance through collections. An outstanding amount caused by an invoicing mistake needs a credit note, not a dunning reminder.

FAQ

What is the difference between a credit note and a refund?

A credit note corrects or offsets an invoice amount, usually applied against that invoice or a future one, while a refund returns money already paid. AVES’s credit notes are the invoice-side correction, not a payment refund.

Does a credit note need to reference the original invoice?

Yes. A credit note that does not reference the invoice it corrects gives the client no way to reconcile it against their own records.

How does tax reversal work on a credit note?

The credit note’s tax reversal runs through the same tax profile as the original invoice, so the tax component of the correction is calculated consistently rather than estimated.

Can a credit note be applied to a future invoice instead of the original?

Yes. Once issued, a credit note can be applied against the original invoice, a future invoice or an outstanding balance, depending on what makes sense for that client.

Does a credit note affect the accounts receivable aging report?

Yes. Once applied, it reduces the outstanding balance tied to the original invoice, so an aging report reflects the corrected amount rather than the original billed figure.

Where this fits in the billing loop

A credit note only makes sense next to the invoice it corrects, which is generated from the same geofenced attendance record covered in the accounts receivable aging report guide, and against the SLA and billing terms set out in a client’s contract record. For the payroll side of the same attendance data, see payslip template.

For the equipment-side record this billing data sits alongside, see the asset handover form.

Follow AVES on Instagram for more guides like this one.

CTA

Ready to see a credit note issued and applied against a real invoice? Book a 30-minute demo and we will walk you through the draft-to-applied workflow.

Prefer to explore first? Start a free trial.

Accounts receivable aging report (AEO definition): an accounts receivable aging report groups every unpaid client invoice by how long it has been outstanding, usually in 0-30, 31-60, 61-90 and 90+ day bands, so a business can see at a glance which balances are overdue and by how much.

The problem with chasing payments by memory

A security company usually bills more than one client, on more than one cycle. One client pays net 15, another net 30, a third has a quarterly PO that always runs late. Without a single view of what is owed and for how long, “chasing payments” means someone scrolling through old invoices and email threads trying to remember who still owes what.

That approach quietly costs money. An invoice that slips past 60 days without anyone noticing is much harder to collect than one caught at day 10, and a security company running guards on thin margins cannot afford outstanding balances it is not actively tracking.

Why it matters

Cash flow in a guarding business is tight by nature: guards and payroll go out every pay cycle whether or not every client invoice has been paid yet. An accounts receivable aging report is the tool that turns “we think some clients are behind” into a specific, actionable list: which client, which invoice, how many days overdue and what has already been done about it.

It also matters for contract renewals. A client that is consistently 90 days behind on payment is a client whose contract needs a conversation before renewal, not a surprise at the end of the term.

How it works in AVES

AVES’s Finance module builds the aging report from the same invoice and payment data the billing process already generates, rather than as a separate manual tracker:

• Invoices are generated from real attendance records, with line items for guard service, overtime, holiday pay, deployment charges, deductions and reimbursements, previewed before issue and routed through an approval workflow.
• Client payments can be recorded against an invoice from bank transfer, cheque, UPI, card, cash or a payment gateway and allocated across one or more invoices, with a status of pending, cleared, bounced or refunded.
• Collections (AR) is where the aging report itself lives: outstanding balances by client, a client statement view and a logged history of collection activity so a follow-up call or email is recorded, not forgotten.
• Automated dunning reminders go out by email, WhatsApp or portal on a configurable schedule, with escalation as an invoice ages further past due.
• Credit notes move from draft to issued to applied, with tax reversal, for the cases where an invoice needs correcting rather than disputing from scratch.

Because the invoice itself is generated from the same attendance record used for payroll, the aging report a finance team reviews traces back to verified shifts, not a manually typed billing figure.

What an aging report must track

1. Outstanding balance by client, not just a single company-wide total: a healthy overall number can still hide one client who is badly behind.
2. Aging buckets: 0-30, 31-60, 61-90 and 90+ days overdue, so the oldest and riskiest balances are visible immediately, not buried in a long invoice list.
3. Linked invoice and contract detail: which specific invoice is overdue, and under which contract’s billing cycle and payment terms it was issued.
4. Collection activity log: every reminder, call or email tied to that balance, so a follow-up has a record instead of starting from zero.
5. Dunning status and escalation stage: whether an automated reminder has gone out, and what the next escalation step is if it goes unpaid.
6. Payment allocation: which payments have already been applied to which invoices, so the outstanding figure is current, not stale.

Common mistakes

• Tracking one lump “total owed” figure instead of per-client ageing. A single number hides exactly which relationship needs attention.
• Treating every overdue invoice the same. A balance at day 5 and a balance at day 95 need different responses; an accounts receivable aging report that does not separate them by bucket cannot drive the right escalation.
• Leaving collection calls unlogged. If a reminder call is not recorded anywhere, the next person chasing that client has no idea it already happened.
• Reconciling payments manually against invoices. Without allocation tracked against the specific invoice, it becomes unclear which balance is genuinely still outstanding.

Getting started with an aging view

A security company does not need to overhaul its whole billing process to get value from an accounts receivable aging report. The first useful step is simply pulling every open invoice into one list and sorting it by days overdue. That alone usually surfaces one or two clients who have quietly drifted past 60 or 90 days without anyone flagging it.

From there, the aging buckets matter more than the raw total. A finance team that reviews the 90+ bucket weekly, even briefly, catches a slow-paying client long before it becomes a bad debt write-off. Pairing that review with a logged collection activity trail, so every reminder and call is recorded against the invoice, means the next person chasing that balance is not starting from zero.

FAQ

What are the standard aging buckets in an accounts receivable report?

Most aging reports use 0-30, 31-60, 61-90 and 90+ day bands measured from the invoice due date, which is also how AVES’s Collections module groups outstanding balances.

Does AVES generate invoices automatically?

Invoices are generated from real attendance records with line items for guard service, overtime, holiday pay, deployment charges, deductions and reimbursements, then previewed and routed through an approval workflow before being sent.

How are overdue clients reminded to pay?

Through automated dunning reminders sent by email, WhatsApp or portal on a configurable schedule, with escalation as a balance ages further.

Can a security company see outstanding balance per client, not just a company total?

Yes, the Collections (AR) view in AVES shows outstanding balances and a client statement per client, alongside the logged history of collection activity for that account.

What happens if an invoice needs correcting?

A credit note can be raised, moving from draft to issued to applied with tax reversal, rather than reissuing the whole invoice.

Where this fits in the billing loop

Client billing starts with the same verified hours that drive payroll. Guards clock in through geofenced attendance, that record feeds both the payslip template on the payroll side and the invoice line items on the billing side, and this aging report is where a finance team tracks whether those invoices actually get paid.

For the staff-accountability side of the business, see asset handover forms and key control and for the roster data that drives per-shift billing, see the security guard duty roster.

Follow AVES on Instagram for more guides like this one.

CTA

Want to see a live accounts receivable aging report built from real attendance data? Book a 30-minute demo and we will walk through the Collections view with you.

Prefer to explore first? Start a free trial.

Types of security guards: the different categories of guard deployment — armed vs unarmed, static vs mobile patrol, in-house vs contract, and event or specialist coverage — each suited to a different risk profile and site.

“Security guard” covers a wide range of roles, and the types of security guards behave very differently on the ground. A static post officer at a warehouse gate, an armed guard at a cash facility and a mobile patrol covering a business park are not doing the same job, and a site that hires the wrong type ends up with either gaps in coverage or wasted spend. Here is how the main categories break down, and what actually needs to be tracked for each once they are deployed.

Why the distinction matters

Each guard type carries a different set of obligations: an armed guard needs licensing and use-of-force documentation a static unarmed officer does not; a mobile patrol officer needs GPS/checkpoint proof an in-house fixed-post guard does not; a contract guard’s hours and coverage need to be verifiable back to the client in a way an in-house employee’s do not. Picking the right type — and then managing it correctly — is a coverage decision as much as a cost one.

The Main Types of Security Guards

• Static / fixed-post guards — stationed at one location such as a gate, lobby or checkpoint. Focus is access control and visible presence rather than movement.
• Mobile / patrol guards — cover multiple checkpoints or a wider site (or multiple sites) on a moving route, usually with scheduled checkpoint visits.
• Armed guards — licensed to carry a weapon, typically deployed for high-risk sites such as cash-in-transit, banks or critical infrastructure. Comes with stricter reporting requirements.
• Unarmed guards — the majority of commercial and residential deployments: access control, visitor management, patrol and incident reporting without a weapon.
• In-house guards — employed directly by the organisation they protect, usually for a single site with long-term familiarity.
• Contract / outsourced guards — supplied by a security company under a service agreement, often covering multiple client sites; coverage and hours need to be independently verifiable.
• Event security — short-term deployment for a specific event: crowd management, access control and incident response for a defined window.
• Specialist guards — roles such as K9 units, close-protection officers or lone workers covering remote or single-officer sites, each with its own risk profile.

What has to be tracked once a guard type is deployed

Whatever the category, the operational gap is the same: proving a guard was where they were supposed to be, doing what they were supposed to do. AVES covers this across guard types rather than building a separate tool for each:

• Patrol handles mobile and multi-site guards — QR-checkpoint patrols with GPS location, scan timestamps and an optional selfie, so a moving guard’s route is provable rather than assumed.
• Daily Briefing covers static and shift-based deployments — per-shift briefing with officer attendance, a live property overview and follow-up items, so a fixed-post team stays coordinated across shift changes.
• Attendance (geofenced) applies to in-house and contract guards alike — location-verified clock-in/out, which matters most for contract guards whose hours need to be checked independently of the vendor’s own timesheet.

None of this changes the category of guard a site needs — that is a risk assessment, not a software decision — but once the type is chosen, the record-keeping requirement is the same across all of them: proof of presence, proof of activity and a shift-level audit trail.

Common Mistakes When Choosing Types of Security Guards

• Defaulting to unarmed everywhere without a real risk assessment for high-value or high-risk sites.
• Treating contract guards like in-house staff — without independent attendance verification, a client has no way to confirm the hours a vendor bills.
• No patrol proof for mobile officers — a static log entry (“did a round, all clear”) without checkpoint or GPS data is not verifiable after the fact.
• Mixing static and mobile expectations — assigning patrol-level checkpoint coverage to a single fixed-post guard, or vice versa, creates coverage gaps.

FAQ

What are the main types of security guards?
Static/fixed-post, mobile/patrol, armed, unarmed, in-house, contract, event and specialist (K9, close-protection, lone worker) guards — categorised by deployment style, licensing and employment relationship.

What’s the difference between in-house and contract security guards?
In-house guards are employed directly by the site they protect; contract guards are supplied by an outside security company under a service agreement, often covering several client sites, which means their hours need independent verification.

Do all types of security guards need the same reporting?
No — armed guards carry stricter use-of-force and licensing reporting, mobile guards need patrol/checkpoint proof, and contract guards need attendance that the client can verify independently of the vendor.

Choosing the Right Type of Security Guard for Your Site

Matching the right type of security guard to a site starts with a risk assessment, not a budget line. A retail store with high foot traffic usually needs a visible static or unarmed guard focused on deterrence and customer interaction. A cash-in-transit route or a facility holding high-value assets needs an armed guard with the licensing and reporting that role requires. A large logistics yard or a multi-building campus is better served by mobile patrol guards on a checkpoint route than by a single fixed post that cannot see the whole perimeter.

Budget and headcount matter too: a contract guarding company can flex the types of security guards deployed across a client’s sites as risk changes, while an in-house team is usually fixed in size and needs cross-training so static and mobile duties can be covered by the same staff during shortfalls. Whichever mix of types of security guards a site settles on, the deployment only works if attendance, patrol and incident activity are actually recorded — otherwise the coverage decision cannot be verified after the fact.

Follow AVES Security on Instagram for more security operations tips.

---

Managing a mix of static, mobile and contract guards across sites? Book a 30-minute demo and we’ll show how Patrol, Daily Briefing and geofenced Attendance track each deployment type. Prefer to explore first? Start a free trial.

Related reading: security guard duties and responsibilities, guard tour system, geofence attendance, and security patrol report: 7 things every report must record.

A workplace violence prevention plan is a written document that sets out how an organisation identifies the risk of violence at its sites, what staff must do when a threat appears, how every incident and near miss is recorded, and who reviews the record afterwards. It is a prevention and response system, not a policy statement filed in a drawer.

Most organisations discover the gaps in their workplace violence prevention plan on the worst possible day. A contractor becomes aggressive at the gate. A dismissed employee comes back to the car park. A customer escalates at a reception desk and a lone officer has to decide, in about four seconds, whether this is a de-escalation or a code call.

What separates a plan that works from a plan that exists is whether the answers were decided in advance and whether the record holds up afterwards. This guide covers the seven parts a workplace violence prevention plan needs, the mistakes that hollow one out, and where a security platform fits – which is not writing your policy, but proving what actually happened.

Why a workplace violence prevention plan matters

Violence at work is rarely a single unexpected event. It is usually the end of a sequence: a complaint nobody logged, a threat somebody mentioned verbally, an aggressive visitor who was turned away but never recorded, a door fault that let someone into a controlled area. Each one on its own looks minor. Together they are a pattern – and a pattern is only visible if the individual events were written down.

That is the first reason a plan matters. It forces the low-level events into a record where the pattern can be seen before it escalates.

The second reason is legal exposure. Where an incident goes to an insurer, a regulator or a court, the questions are predictable. Did you assess the risk. Did staff know what to do. Was the earlier warning reported. What did you do about it. An organisation that can answer those with dated records is in a very different position from one answering from memory.

The third reason is the people on shift. Guards, receptionists and lone workers are the ones who meet the threat first. A plan tells them what is expected of them, which is the difference between a considered response and an improvised one.

How a workplace violence prevention plan works

A plan runs as a loop, not a document. It has four moving parts.

Assess. Identify where violence is plausible at each site – the gate, reception, cash handling, night shifts, lone-worker posts, car parks – and what makes each one riskier.

Prevent. Put the controls in place that lower that risk: access control at entry points, working panic buttons and intercoms, defined lone-worker posts, and briefings that tell the shift what to watch for today.

Respond. Define what happens the moment a threat appears. Who is called, what code is activated, who takes command, who meets the emergency services, and what the person on the spot does while that is happening.

Record and review. Capture the event while the detail is fresh, investigate it, decide the corrective action, and close it with a named reviewer. This is the half that most plans skip and the half that determines whether anything improves.

The first three are written by your organisation. The fourth is where a system earns its place, because it is the part that depends on a record being made consistently, under pressure, by whoever happened to be on duty.

The 7 parts every workplace violence prevention plan needs

Use this as a checklist against your current plan. Each part maps to what AVES actually records.

1. A site-by-site risk assessment. Not a corporate statement – a list of the specific posts and situations where violence is plausible, and the control applied to each. A plan that does not name locations cannot be acted on by the people standing in them.
2. Definitions and a reporting threshold. Staff need to know what counts. Verbal abuse, threats, intimidation, physical contact and property damage should each be named, with a clear instruction that the low-end events get reported too. If only assaults get reported, you have deleted your own early-warning data.
3. A reporting channel that works on shift. A form the guard can complete on the phone at the post, not a template on an office PC. In AVES, a violent or threatening event is captured on an incident form, with the 6-sided photo capture plus video and audio for evidence, the findings, the actions taken and a police-report reference where one exists. A verbal account that never becomes a record is a gap in the plan.
4. Witness and statement capture. The account of the person who was there, taken while it is fresh. AVES has a dedicated security and witness statement form for exactly this, so the bystander’s version sits alongside the officer’s rather than being lost. Two independent accounts recorded on the day are worth far more than one recollection three weeks later.
5. Near-miss and hazard reporting. The threat that did not land, and the physical condition that makes violence easier – a jammed door, a broken intercom, a dead panic button, an unlit car park. AVES records these as safety and defect reports, each carrying a hazard reference, photos, resolved-state photos and a reviewer sign-off, so the fix is evidenced rather than assumed. The six equipment checklists cover the emergency telephone, electro-magnetic door, emergency door, intercom, panic button and radio on a fault to action to review cycle. If your panic buttons are not on a checked cycle, your escalation path is a hope.
6. An emergency code and escalation path. One agreed trigger, one command point, one set of roles. AVES models this as a code activation record: the command centre, the emergency response and crisis management team rosters, the arrival of ambulance, police or fire, and a narration of how the event unfolded. Recording arrivals and timings matters because after a serious event the timeline is the first thing anybody asks for.
7. Briefing, follow-up and review. The plan has to reach the shift that is standing on site now. The AVES daily briefing carries the shift’s officers and attendance, discussion topics and a follow-up list where each item has a status and a remark – so “watch the east gate, we had an aggressive visitor last night” is a tracked item rather than a passing comment. Review then closes the loop: incidents and near misses are read together, and the controls in part 1 are changed when the record says they should be.

A plan with parts 1, 2 and 6 is common. A plan with all seven is rare, and it is the reporting and review parts – 3, 4, 5 and 7 – that make the difference in practice.

Common mistakes that hollow out a plan

Writing a policy instead of a procedure. A document that states the organisation does not tolerate violence commits to a value but tells nobody what to do at 02:00. Every section should end in an action by a named role.

Setting the reporting threshold too high. If staff only report incidents that result in injury, the near misses and verbal threats vanish, and with them the pattern that would have predicted the serious event.

Keeping the record on paper. A paper incident book at a post has no photographs, no timestamps that cannot be rewritten, and no way for a supervisor at another site to see it. It also tends to be the item that goes missing after a contested event.

Never closing an item. Reports go in, nothing visibly comes back, and staff stop reporting. Follow-up with a status and a named reviewer is what keeps the channel alive.

Reviewing annually and nowhere else. A plan reviewed once a year is a plan that stays wrong for up to twelve months. Incidents and defect reports should feed the review continuously.

Where AVES fits

To be direct about scope: AVES does not write your workplace violence prevention plan and does not author policy. What it does is hold the operational half – the part that has to happen on shift, under pressure, and survive scrutiny afterwards.

That means incident and witness statements captured at the post with photo, video and audio evidence attached. Safety and defect reports that carry a hazard through to a photographed resolution with a reviewer’s sign-off. Equipment checklists that keep panic buttons, intercoms and emergency doors on a fault to action to review cycle. Code activation records that capture command, the response-team roster, emergency-service arrivals and the narration. Daily briefings that push the day’s risk to the shift and track the follow-up.

One honest note on how sign-off works: there is no signature image anywhere in AVES. Sign-off is an accept, decline or submit action tied to a named user with a date and time – an audit trail rather than a scrawl, which is both harder to dispute and easier to search when someone asks who reviewed what.

Frequently asked questions

What is a workplace violence prevention plan?

It is a written plan setting out how an organisation identifies the risk of violence at its sites, prevents it, responds when it occurs, and records and reviews every incident and near miss. It covers prevention, response and the record, not just a statement of policy.

What should a workplace violence prevention plan include?

A site-by-site risk assessment, clear definitions and a low reporting threshold, a reporting channel staff can use on shift, witness statement capture, near-miss and hazard reporting, an emergency code and escalation path with named roles, and a briefing, follow-up and review cycle.

What is the difference between a workplace violence prevention plan and a policy?

A policy states the organisation’s position on violence. A plan tells named roles what to do, in what order, and how the event gets recorded. A policy without a plan gives staff nothing to act on.

How often should the plan be reviewed?

At a fixed interval and after every reported incident or significant near miss. A plan reviewed only on an annual cycle can stay wrong for a year, which is why the incident and defect record should feed the review continuously.

Does AVES write the plan for us?

No. AVES is the record and response layer around the plan. It captures incidents, witness statements, near misses, equipment faults, code activations and briefings, so the plan you write is actually executed and evidenced on site.

See how an incident, a witness statement and a code activation are recorded on the real screens. Book a 30-minute AVES demo and we will walk you through the actual guard-app and admin screens, not a mock-up. Book a demo or start a free trial.

Internal links: Incident Reporting Software (hub) · Incident Report Form · Near Miss Report Form · Use of Force Report · Witness Statement Form · Security Guard Logbook (related hub). External: AVES on Instagram (DoFollow).

An equipment sign out sheet is a running log that records who took a piece of kit, when they took it, the condition it was in, and whether it came back. It turns shared gear — radios, torches, keys, body cameras, first-aid bags — into an accountable trail instead of a guessing game.

Every security operation runs on shared equipment. A handful of radios, a set of master keys, a thermal torch, a body-worn camera, a first-aid kit that has to be complete when the next shift needs it. The moment two guards share one radio across a shift change, someone has to know who has it now — and who had it when it stopped working. An equipment sign out sheet is how that question gets answered.

Done well, it is the difference between “the radio is missing and nobody knows who touched it last” and “the radio went out to Officer Rai at 19:04, came back at 07:12 with a cracked antenna, logged by the incoming supervisor.” This guide covers the eight columns a checkout log actually needs, the mistakes that make one useless, and how AVES turns the paper version into a system that will not let an item quietly disappear.

Why an equipment sign out sheet matters

Shared kit is expensive and it is easy to lose. A single lost radio or master key set is a direct replacement cost, and a lost key can force a lock change across a whole site. But the bigger cost is accountability. When a client asks “who had access to the server-room key on Tuesday night,” a shrug is not an answer — it is a liability.

A proper sign out sheet does three things at once. It fixes responsibility, so the person holding an item is on record. It surfaces damage early, because condition is checked at issue and return rather than discovered later. And it creates a defensible record, so when something is lost or broken you can show exactly when it left, who signed for it, and what state it was in. That record is what protects the guard, the supervisor and the company when a dispute lands.

How an equipment sign out sheet works

The flow is simple and it is the same whether you run it on paper or in an app. An item is issued to a named person, its condition and identifiers are recorded, and the entry stays open until the item is returned and checked back in. The item is either out or in at any moment, and every change of hands is stamped with who did it and when.

Paper handles the first half of that well enough. Where it falls down is the second half — the return. A paper sheet has no way to flag an item that never came back, no way to attach a photo of the damage, and no way to stop the row being quietly rewritten. That is the gap a system closes, and it is worth understanding the columns first because the columns are the same either way.

The 8 columns every equipment sign out sheet needs

A checkout log is only as good as the fields it forces people to fill in. These are the eight that matter, mapped to how AVES records them.

1. Item name or description. What is going out — “Motorola handheld radio,” “master key set B,” “first-aid grab bag.” In AVES this is the item line on a Gate Pass or the item name in a shift handover’s equipment list. Vague entries like “radio” are useless when there are six of them.
2. Serial or asset number. The unique identifier that ties the row to one physical object. AVES stores a serial number against issued items so “radio 4” and “radio 5” never get confused, and a returned item can be matched to the exact one that left.
3. Quantity and condition at issue. How many, and what state they are in. Shift handover records a count and a condition per item so the person receiving kit is signing for its condition, not just its existence — a scratched torch noted at issue is not a dispute at return.
4. Issued to (collected by). The named person taking the item. AVES captures this as the collected-by field on a Gate Pass, so the item is tied to an individual, not to “the night team.”
5. Date and time out, and who issued it. When the item left and which supervisor released it. AVES stamps the checkout with the issuing user and a checked-by record, so there are two names on every issue — the person taking it and the person releasing it.
6. Expected return. When the item is due back. This is what lets a supervisor spot an overdue item before it becomes a lost item, rather than finding out at the end of the week.
7. Returned date, by whom, and return condition. The other half of the loop. AVES records the return date and the returning person, and — importantly — supports a photo of the item as it comes back so “it was already cracked” can be checked against how it went out.
8. Status and loss trail. Whether the entry is open, returned, or lost — and if lost, the follow-up. AVES carries a status on every item and, through its key control workflow, a lost-item trail with a recorded fine amount and receipt number so a loss is documented and closed, not just noted and forgotten.

Those eight columns are the spine of any template — whether you build it in Excel, print it as a PDF, or run it in an app. If your current sheet is missing the return condition and the status column, it is a sign out sheet in name only.

Common mistakes that make a sign out sheet useless

The most common failure is no return column. Plenty of sheets record beautifully who took what, and then have nowhere to record that it came back — so every item looks permanently checked out and the log tells you nothing.

The second is skipping condition at issue. If you only note condition on return, every bit of damage becomes an argument. Recording it at both ends removes the dispute entirely.

The third is an editable, unstamped record. A paper row can be rewritten and a shared spreadsheet can be quietly changed, which is exactly the wrong property for an accountability record. Entries need to be stamped with who and when, and they need to be hard to alter after the fact.

The fourth is relying on a signature scribble as proof. A signature on paper proves very little six months later. It is worth being clear here: AVES does not capture a signature image. Instead, sign-off is an accept, decline or submitted action tied to a named user with a date and time — an audit trail rather than a scrawl, which is both harder to forge and easier to search.

How AVES turns the equipment sign out sheet into a system

AVES records equipment movement across a few connected workflows rather than one loose form. Items going out through a controlled point are logged as a Gate Pass, with the item list, serial numbers, photos at issue, the person collecting, the person checking, and a return record with a return photo and status. Kit passed between shifts is captured in the shift handover, where each item carries its count and condition and the incoming guard acknowledges it. Keys run through a dedicated key control workflow with request, issue, return, and a lost-key trail that records a fine amount and receipt number.

The point is not the individual field names — it is that every movement is tied to a named person and a timestamp, the return half of the loop is enforced rather than optional, and the record cannot be quietly rewritten. That is what a paper sheet can never give you: not a prettier form, but a log you can actually stand behind when a client asks who had the key.

One honest note on scope: AVES records these movements as they happen through the guard app. It does not auto-reconcile a full equipment register on its own — that roll-up view is on the roadmap, not shipped today. What ships today is the accountable trail for each item as it moves.

Frequently asked questions

What is an equipment sign out sheet?

It is a log that records who took a piece of shared equipment, when they took it, the condition it was in, and when it was returned. It exists to fix responsibility for shared kit and to create a record you can rely on if something is lost or damaged.

What columns should an equipment sign out sheet have?

At minimum: item name, serial or asset number, quantity and condition at issue, who took it, date and time out, expected return, actual return date and condition, and a status column. Missing the return and status columns is the most common reason a sheet fails.

Is an Excel or PDF equipment sign out sheet good enough?

An Excel or PDF template is fine for a low-volume, single-site setup and it is a good starting point. It breaks down when items move often, across shifts or sites, because a spreadsheet cannot flag an overdue item, cannot attach a photo of damage, and can be edited after the fact. At that point a system that stamps and locks each entry is worth the switch.

How does AVES prove an item was returned?

Each return is recorded against a named person with a date and time, a status change, and — for gate-pass items — a photo of the item as it came back, so its return condition can be checked against how it left. Sign-off is a recorded accept or submit action rather than a signature image.

See the equipment trail on the real screen

Book a 30-minute AVES demo and we will walk you through how a gate pass, a shift handover and a key issue are logged, returned and closed — with the actual guard-app screens, not a mock-up. Book a demo or start a free trial. Follow AVES on Instagram for more guard-ops guides.

A contractor sign in sheet is the record, kept at the gate or reception, of every contractor who comes on site to work. It captures who they are, who they work for, why they are there and when they arrive and leave. Unlike a visitor who is escorted for a meeting, a contractor is often on site for hours, moving through areas staff do not watch, sometimes doing work that carries its own risk. The sign in sheet is where accountability for that starts.

Most contractor sign in sheets fail for one reason: the template is missing the fields that matter, so the record has gaps exactly where you later need proof. This guide sets out the eight fields every contractor sign in sheet template should have, and why a digital sheet closes the gaps a paper one cannot.

Why a contractor sign in sheet matters

A contractor is not a guest. They carry tools, they may work alone in a plant room, and the task itself, hot work or an electrical isolation for example, can be the very thing that causes an incident. The sign in sheet is the first control that ties a named person to a company, a task and a window of time on your site.

It matters in three moments. In an evacuation it tells the fire marshal how many contractors are still inside and where they were working. In a safety review it links each person to the permit or approval that authorised their work. After an incident it answers the question every investigation opens with: who was here, and who let them in.

The weakness of the paper sheet is that it relies on the contractor to fill it in fully and honestly, and on nobody being able to walk past the desk unchecked. A clipboard left on a counter is not a control at all. That is what the right fields, and a digital format, are there to fix.

The 8 fields every contractor sign in sheet needs

1. Contractor name – the full name of the individual, so the entry is attributable to a person and not just a company.
2. Company – the firm the contractor represents, so you can trace the work back to a supplier.
3. On-site contact or host – the member of staff who authorised the work and is responsible while the contractor is on site.
4. Purpose of work – what the contractor is there to do, in enough detail to match it against any permit.
5. Permit or approval reference – the number of the work permit or access approval that authorised entry, where the task requires one.
6. Time in – the arrival time, recorded at the gate.
7. Time out – the departure time, recorded when the contractor leaves. This is the field paper sheets lose most often, and the one an evacuation depends on.
8. Pass or badge number – ties the contractor to the physical or digital pass they were issued for the day.

Higher-risk sites add two more: a photo of the contractor and a scan of a photo ID, so the person at the gate can match the badge to the face. In AVES, each access pass is issued with an approval step, a QR code and an id or profile photo, so the entry is tied to a verified identity rather than a name written by hand. Where the work is hazardous, the hot work permit adds an invitation, an approval, a QR check-in and a terms and conditions acknowledgement on top of the sign in, so a contractor cannot start high-risk work without an authorised permit on record.

Paper sign in sheet versus a digital one

A paper template works until the moment it matters. The recurring failures are always the same: the time-out field left blank, handwriting no one can read, a permit reference nobody wrote down, a page that has gone missing. None of these is visible until you need the record and find it incomplete.

A digital contractor sign in sheet captures the same eight fields as structured data. Required fields cannot be skipped, entries are legible because they are typed or selected, and the departure is recorded when the pass is scanned or returned rather than relying on the contractor to sign out. The record is searchable, so you can pull every visit by one firm, or everyone on site during a shift, in seconds. For the full workflow around passes, approvals and access, see the AVES visitor management system. To see how contractor access differs from payroll-style management, see contractor management for security teams.

Common contractor sign in sheet mistakes

No sign-out. The single most common gap. Without a time out you cannot prove when a contractor left or run an accurate evacuation count.

No permit link. A contractor doing hazardous work with no permit reference on the sheet means there is no record that the work was ever authorised.

An unattended clipboard. A sheet on the counter with no one checking it lets anyone write anything, or nothing.

No named host. If no staff member authorised the work, no one is accountable for where the contractor goes or what they do.

No identity check. A name with nothing behind it is trivial to fake, and a contractor pass is easy to reuse the next day.

Keeping old sheets on display. A completed sheet shows every prior contractor’s details to the next person who signs in. That is a privacy failure. Records should be stored securely, not left face-up on the desk.

Contractor sign in sheet checklist

• Every entry has a contractor name, company and named host.
• Purpose of work is recorded in enough detail to match a permit.
• A permit or approval reference is captured where the task requires one.
• Both time in and time out are recorded.
• A pass or badge number ties the person to a pass issued for the day.
• Higher-risk sites add a photo and ID check.
• The sheet is controlled by a person, not left unattended.
• Prior entries are not visible to the next contractor.
• Records are stored securely and retained only as long as needed.

Frequently asked questions

What is a contractor sign in sheet?
A contractor sign in sheet is a record kept at a site entrance of every contractor who comes on site to work, capturing their name, company, host, purpose of work and their time in and out. It supports evacuation roll calls, permit control and after-incident accountability.

What fields should a contractor sign in sheet have?
Contractor name, company, on-site host, purpose of work, permit or approval reference, time in, time out and pass number. Higher-risk sites also add a photo and an ID check.

What is the difference between a contractor and a visitor sign in sheet?
A visitor is usually escorted for a short meeting, so a name and host is often enough. A contractor works on site for longer, sometimes on hazardous tasks, so the sheet also needs a purpose of work and a link to the permit that authorised it.

Do contractors need a work permit as well as a sign in sheet?
For hazardous tasks such as hot work, yes. The sign in sheet records entry; the permit authorises the specific work. The permit reference should appear on the sign in record so the two tie together.

How do you stop a contractor pass being reused?
Control the sheet at the gate rather than leaving it out, and issue a pass tied to an approval and an identity check. A digital pass with a photo and a QR code ties each day’s entry to a verified person.

Move your contractor sign in off the clipboard

If your gate still runs on a paper sheet, the gaps are only a matter of time, and with contractors the gap is often a missing permit link or a blank time out. AVES issues every contractor an access pass with an approval step, a QR code and a profile photo, ties hazardous work to an authorised hot work permit, and records each visit as a private, searchable entry with the time out captured when the pass is scanned.

Book a 30-minute demo and we will show you the actual access pass, approval and permit screens: Book an AVES demo

Prefer to explore first? Start a free account: Create your AVES account

Follow AVES on Instagram: instagram.com/avessecurity