Category: Security Operations

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.

Contract management software (AEO definition): for a security company, contract management software is the system that stores each client’s SLA terms, billing model and payment terms against one record, so billing and service delivery can be checked against what was actually agreed.

The problem with contracts living in a filing folder

A security contract is not just a signed PDF. It sets the response time a client expects, how many patrols per shift are owed, a minimum attendance percentage and a penalty if that is breached, plus the billing model and payment terms the invoice should follow. When that detail only lives in a filed document, nobody checking a monthly invoice or a missed patrol can quickly confirm what was promised.

The result is a slow drift: a site gets billed on the wrong rate card for months, a contract auto-renews without anyone noticing the SLA terms changed or a client disputes a penalty clause because operations never had the contract terms in front of them when the breach happened.

Why it matters

Security contracts carry real financial exposure. A penalty-per-breach clause only protects the client if someone is actually tracking attendance against the minimum percentage it refers to. A billing model that is not applied consistently means invoices do not match what the client agreed to pay, which is the fastest way to create a payment dispute.

It also matters operationally: PO tracking and payment terms determine when a company can expect to be paid, and an auto-renew clause that nobody is watching can lock in outdated terms for another year.

Multi-site clients make this harder still. A single contract can cover several sites under one SLA, each with its own patrol count and minimum attendance percentage, so contract management software has to hold those site-level terms against one client record rather than forcing a separate filed document per site. Without that, a billing dispute on one site means checking a different document to the one covering the client’s other sites and the penalty-per-breach clause risks being applied against the wrong site’s attendance figures.

How it works in AVES

AVES is not general-purpose contract management software built for every industry. It keeps each client’s contract terms attached to the same record that drives billing and service tracking, inside the Finance module:

• Clients hold the core record for each client relationship.
• Contracts store SLA terms (response time, patrols per shift, minimum attendance percentage, penalty per breach), the billing model (per guard per month, per hour, per shift or fixed monthly), the billing cycle, payment terms, PO tracking, auto-renew and any attached documents.
• Rate cards and tax profiles sit per organisation, so the billing model on a contract maps to an actual rate rather than a manual figure typed at invoice time.
• Invoices are generated from real attendance records, so the billing model on the contract has something concrete to apply to.

Because the contract record and the invoice record sit in the same module, a billing dispute can be checked against the actual SLA terms rather than a filed document nobody has open.

What contract management software must track

1. SLA terms: response time, patrols per shift and minimum attendance percentage, the measurable commitments a client will hold the company to.
2. Penalty per breach: what happens and how it is calculated, if an SLA term is missed.
3. Billing model: per guard per month, per hour, per shift or fixed monthly, set once and applied consistently.
4. Billing cycle and payment terms: how often invoices go out and how long the client has to pay.
5. PO tracking: the purchase order reference an invoice needs to match, where a client requires one.
6. Auto-renew status: whether the contract rolls over automatically and on what terms.
7. Attached documents: the signed contract itself, kept against the record the billing model reads from.

Common mistakes

• Billing from memory instead of the contract record. If the billing model lives only in someone’s head, a staffing change means the next invoice quietly uses the wrong rate.
• Treating SLA terms as a one-time read. A penalty-per-breach clause is only enforceable if attendance is actually measured against the minimum percentage it names.
• Letting auto-renew pass unreviewed. A contract that rolls over without a review can lock in a rate card or SLA term that no longer fits the site.
• Losing the PO reference. An invoice that does not match a client’s PO number is the easiest invoice for their accounts-payable team to reject.

FAQ

Is AVES general-purpose contract management software?

No. AVES keeps contract SLA terms, billing model and payment terms attached to the same client record that drives attendance-based invoicing for a security company, rather than acting as a standalone enterprise CLM platform.

Can a contract set a different billing model per client?

Yes. Each contract’s billing model can be per guard per month, per hour, per shift or fixed monthly, applied with that client’s own rate card.

Does AVES track SLA breaches automatically?

SLA terms such as minimum attendance percentage are stored on the contract and attendance is measured through geofenced attendance records, so a breach can be checked against the contract’s own penalty clause.

What happens when a contract auto-renews?

Auto-renew is a setting on the contract record, so whether a contract rolls over and on what terms, is visible on the same record rather than left to a filed document.

Can a client’s signed contract document be stored with the record?

Yes, attached documents keep the signed contract against the same record the billing model and SLA terms are read from.

Where this fits in the billing loop

A contract’s billing model only means something once it is applied to real hours worked, which is why it connects to geofenced attendance and feeds the same accounts receivable aging report that tracks whether invoices built from the contract get paid on time. Payroll built from the same attendance record is covered in the payslip template guide and for the credit side of invoicing, see credit note template.

For the operational record a contract’s SLA terms get measured against, see the security guard duty roster.

Follow AVES on Instagram for more guides like this one.

CTA

Ready to see contract SLA terms, billing and attendance tied to one client record? Book a 30-minute demo and we will show you a contract-to-invoice walkthrough.

Prefer to explore first? Start a free trial.

Fixed asset register (AEO definition): a fixed asset register is the single record that tracks every serialised item a security company owns or deploys, such as radios, CCTV units and vehicles, by a unique ID, its current location, who is responsible for it and its condition history.

The problem with tracking assets by spreadsheet

A guarding company accumulates equipment fast: radios, body cameras, torches, CCTV units, patrol vehicles, laptops for the ops room. Most of it is reused across sites and guards, which means it moves constantly. A spreadsheet register can list what a company owns on the day it was typed, but it has no way to confirm where a specific radio is right now or who last had it.

The gap shows up at the worst moments: an annual stocktake turns into a week of phone calls to site supervisors, a departing guard hands back three items instead of five and nobody notices for months or a client audit asks for proof of equipment issued to a specific site and the answer is a guess.

Why it matters

Security equipment is not optional overhead, it is often safety-critical (radios, body cameras) or client-mandated (CCTV serial numbers tied to a contract). A fixed asset register that cannot answer “where is this item and who is responsible for it” cannot support an insurance claim, a client audit or a simple investigation into a missing radio.

It also matters for cost control. Equipment that quietly goes missing gets re-ordered instead of recovered, and a company that cannot see its full asset base cannot plan replacement cycles or spot which site is losing more kit than the rest.

How it works in AVES

AVES treats serialised equipment as assets, which is a distinct concept from bulk stock. The Assets module is built around a few connected pieces:

• Asset onboarding brings each item in with a unique asset ID, using an organisation’s own asset-code prefixes so IDs stay readable across sites.
• Tagging and history trail means every scan of that asset ID, during a checklist, an inspection or a transfer, is logged against the asset, building a timeline rather than a single snapshot.
• Location placement records which site or store an asset currently sits at.
• Transfers between orgs or sites go through a request, authorise and confirm or reject step, so an asset does not simply move because someone carried it.
• Custodian assign and release ties an asset to the person currently holding it, and releases that link when it is handed back.
• Physical stocktakes are scan-to-reconcile: a stocktake run scans asset IDs against the register rather than relying on a manual count.
• Status changes, retirement and defect flagging keep the register current when an asset is damaged, retired or temporarily out of service.

Because every scan writes to the same asset ID, the register reflects what actually happened to each item rather than what a spreadsheet says should have happened.

What a fixed asset register must track

1. Unique asset ID: one identifier per item, consistent across every checklist, inspection and transfer it appears in.
2. Current location: the site or store the asset is placed at right now, not where it started out.
3. Current custodian: who holds the asset, with a clear release step when it changes hands.
4. Transfer history: every request, authorisation and confirmation that moved the asset between sites or organisations.
5. Condition and defect flags: whether the asset is working, damaged or awaiting repair, logged at the point someone noticed.
6. Stocktake record: the last reconciliation scan and whether the asset was found where it was expected to be.
7. Status: active, retired or defective, so a retired asset stops appearing in day-to-day checklists but keeps its history.

Common mistakes

• Mixing assets with bulk stock. A radio with a serial number and a box of gloves are not the same kind of record. Serialised items need individual tracking, not a shared quantity count.
• Letting transfers happen without authorisation. If an asset can move between sites with no approval step, the register drifts from reality within weeks.
• Skipping the custodian release step. An asset that is never formally released stays attached to a guard who left months ago, so nobody knows who actually has it.
• Treating a stocktake as a one-off count. A register only stays trustworthy if reconciliation happens on a cycle, not once a year when an audit is due.

FAQ

What is the difference between a fixed asset register and an inventory system?

A fixed asset register tracks individual, serialised items such as radios or CCTV units by unique ID and custodian, while an inventory or bulk-stock system tracks quantity-based items such as gloves or first aid supplies by category.

Does AVES support transfers between sites?

Yes. Transfers go through a request, authorise and confirm or reject workflow, so an asset’s location only changes once the move is approved.

How does a stocktake work in AVES?

A stocktake is scan-to-reconcile: assets are scanned against the register during the stocktake run rather than counted manually, so any asset not found where it is expected to be is flagged.

Can a damaged asset still be tracked?

Yes. Defect flagging and status changes let an asset stay in the register as damaged or retired rather than disappearing from the record once it is pulled from use.

Is the AVES Assets module a project management tool?

No. It tracks physical serialised equipment such as radios, CCTV units and vehicles. It is not a project or product-roadmap tool.

Where this fits in the operations loop

Asset custody connects to the same guards tracked through geofenced attendance, since the person holding a radio or vehicle is usually the guard on shift at that site. For bulk consumables rather than serialised equipment, see how AVES handles day-to-day inventory management and for the paperwork trail when an item is formally handed over, see the asset handover form.

For the wider equipment-and-site record this register sits alongside, see key control and the security guard logbook.

Follow AVES on Instagram for more guides like this one.

CTA

Ready to see a fixed asset register that updates itself every time an asset is scanned? Book a 30-minute demo and we will walk you through onboarding, transfers and a live stocktake.

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.

Payslip template (AEO definition): a payslip template is the fixed layout a payroll run uses to turn one guard’s hours, pay rate, allowances and deductions into a single document that shows exactly how their net pay was calculated for the period.

The problem with a generic payslip template

Security guarding does not pay like a desk job. One guard might work a day shift, a night differential and two hours of overtime covering a missed handover, all inside the same week. A generic payslip template built for salaried office staff has one line for “basic pay” and nowhere to show where the overtime hours came from or why a deduction was applied.

When a security company runs payroll from a spreadsheet, the template usually survives the first few guards and then breaks: someone copies last month’s formula into the wrong row, an allowance gets applied to a guard who left the site or a reimbursement claim never makes it into the final number. The guard notices before payroll does, because it is their money.

Why it matters

A payslip is the one document every guard reads closely every month. Get it wrong and the dispute lands on a supervisor’s desk, not an HR inbox, because guards escalate pay questions to whoever is in charge of their roster. Get it right consistently and payslip queries stop being a monthly fire drill.

It also matters for the business side: a clean, consistent payslip template is what makes a payroll run auditable. If a client or a labour inspector asks how a specific guard’s pay was calculated for a specific week, the answer needs to come from the record, not from someone’s memory of a spreadsheet formula.

How it works in AVES

AVES does not treat payroll as a bolt-on spreadsheet. The payroll module is built around a few connected pieces:

• Salary templates set the base structure for a role or site, so a new guard is added to payroll with the correct pay structure already applied rather than typed from scratch.
• Payroll calendar defines the pay periods the whole company runs on, so every payslip for a given month covers the same dates.
• Payslips are generated per guard per period from that salary template, combined with the hours actually logged for that guard.
• Reimbursements (travel, uniform, equipment and similar claims) are added to the run rather than paid separately and left off the record.
• Payroll engine with an approval workflow means a payroll run does not go straight to payout. It is reviewed and approved first, with bank files produced for the approved run.
• FinalSettlement handles the exit calculation when a guard leaves, so a leaver’s last payslip is not a manual one-off.

Because AVES also runs geofenced attendance, the hours that feed a payslip come from the attendance record for that guard’s shifts, not from a separate timesheet someone re-types into payroll. That link is what keeps a payslip template defensible: the number on the payslip traces back to a logged shift, not an estimate.

The 7 fields a payslip template must include

1. Guard identity and pay period: name, staff ID, site or post and the exact date range the payslip covers.
2. Basic pay: the base rate from the guard’s salary template for the period, before anything else is added or removed.
3. Overtime and shift differentials: overtime hours and any night, weekend or holiday differential, shown as a separate line so a guard can check it against their actual shifts.
4. Allowances: any fixed allowance the salary template applies (uniform, travel, site allowance), listed individually rather than folded into basic pay.
5. Reimbursements: one-off claims approved and included in this specific run, not carried over silently to next month.
6. Deductions: statutory and other deductions, itemised rather than shown as a single “deductions” total.
7. Net pay and approval trail: the final figure, plus a record that the run was approved before it was paid, so the payslip is not just a claim, it is a reviewed calculation.

Common mistakes

• Treating overtime as a manual add-on. If overtime is typed in after the fact instead of calculated from logged hours, it is the first thing a guard will dispute and the first thing that is hard to defend.
• Skipping the approval step. A payroll run that goes straight from calculation to payout has no checkpoint for catching a wrong rate or a duplicated reimbursement before the money moves.
• Losing reimbursements between systems. When expense claims are tracked somewhere other than payroll, they either get paid twice or missed entirely.
• Improvising the exit payslip. A guard’s final pay, including any outstanding dues, needs the same rigour as a regular payslip, not a rushed manual calculation on their last day.

FAQ

What should a security guard payslip template include that a standard template does not?

It needs a clear breakdown of overtime and shift differentials, since guard pay varies week to week with roster coverage in a way a fixed salaried template does not account for.

Does AVES calculate payroll automatically from attendance?

AVES payroll draws on the geofenced attendance record for logged hours and payslips are built from the salary template plus that attendance data, reimbursements and deductions for the period, with a payroll engine and approval workflow before payout.

How does AVES handle a guard’s final pay when they leave?

Through FinalSettlement, a dedicated exit-settlement process, rather than a manual one-off calculation.

Can allowances and reimbursements differ by site?

Salary templates are set per role or site, so allowances can be structured to match the guard’s actual posting and reimbursements are approved claims added to the specific run.

Does a payslip need to show an approval trail?

Yes. A payroll run that has been through an approval workflow before the bank file is produced gives the business a defensible answer if a payslip is ever queried.

Where this fits in the payroll loop

A payslip is the last step in a chain that starts with attendance. Guards clock in and out through geofenced attendance, that verified time feeds the payroll run described above and the same billing-relevant attendance record is what a security company’s accounts receivable aging report traces back to on the client-billing side. Payroll and client billing are separate modules in AVES, built on the same underlying attendance record rather than two disconnected spreadsheets.

For the wider staff-documentation picture, see how AVES handles performance development plans and employee write-ups and for the operational record this payroll data sits alongside, see the security guard logbook.

Follow AVES on Instagram for more guides like this one.

CTA

Ready to see how AVES turns verified attendance into an auditable payslip? Book a 30-minute demo and we will show you an actual payroll run from attendance to payslip.

Prefer to explore first? Start a free trial.

Security scheduling: the process of assigning guards to shifts so that every post is covered, swap requests are approved through a visible trail rather than a text thread and the published roster can be checked against who is actually on site. Done well, it is a repeatable process, not a weekly scramble.

Why spreadsheet scheduling stops working

A spreadsheet or a shared chat works for scheduling a handful of guards across one site. It stops working the moment a guard needs to swap a shift at short notice, a supervisor is covering three sites or someone needs to prove, after the fact, who was actually supposed to be on duty at a given hour. Nothing in a spreadsheet or a WhatsApp thread survives as an audit trail, edits overwrite each other and a verbal “yes, that’s fine” to a swap request leaves no record of who approved what.

A security guard duty roster already covers the shift patterns (2-shift, 3-shift, 4-on-4-off, rotating nights) that a schedule is built from. Security scheduling is the process layer on top: how the roster actually gets built, published, changed and kept honest as reality moves around it.

Why it matters

An unverified schedule change is a coverage gap waiting to surface. If a swap gets agreed over a phone call and never makes it back into the official roster, the person checking “who’s on site right now” is working from a document that’s already wrong. For a security company billing by shift and answerable to a client’s SLA, that gap is not just an inconvenience, it’s the difference between a documented, defensible schedule and one nobody can stand behind if something goes wrong on an unstaffed post.

How to build a security schedule that holds up

1. Build the roster on a shared calendar

Shift assignment starts on a calendar, not a spreadsheet, one place where every guard’s shift, for every site, is visible to whoever needs to see it. This is the rostering layer: shifts generated and assigned against real coverage needs, not re-typed from last week’s version.

2. Publish shifts so guards can see their own schedule

Once the roster is built, guards need to see their own upcoming shifts directly, rather than waiting for a supervisor to read them out or post a photo of a printed sheet.

3. Let guards request a swap, not just ask around

Shifts change. A guard requests a shift swap through the same system the roster lives in, rather than arranging it privately and hoping someone remembers to update the master sheet.

4. Route every swap through manager approval

A swap request only becomes real once a manager approves it. That approval step is what turns “two guards agreed between themselves” into a schedule change the business can actually stand behind, with a record of who requested it, who approved it and when.

5. Check the published roster against who’s actually there

The roster is a plan. It is only useful once it is checked against reality: who actually checked in, at which site, against what the schedule said should happen. That comparison is where scheduling and attendance meet.

Security scheduling checklist

• Does the schedule live in one shared place guards can check themselves, not a spreadsheet emailed around?
• Can a guard request a shift swap from their own phone, rather than arranging it off the books?
• Does every swap require manager approval before it changes the live roster?
• Is there a record of who requested a change, who approved it and when?
• Does the published schedule get checked against actual attendance, not assumed to be accurate?
• Does the schedule account for fatigue-aware shift patterns, not just filling slots?

Common mistakes in security scheduling

• Approving swaps verbally with nothing logged. A spoken “that’s fine” leaves no trail if the swap is later disputed or the post ends up uncovered.
• Treating the roster as fixed once published. A schedule that cannot absorb a same-day swap request just gets worked around off the books, which is worse than no schedule at all.
• Never checking the schedule against attendance. A roster nobody compares to who actually showed up is a plan, not a record. Pair it with geofenced attendance to close that loop.
• Ignoring the handover between shifts. A clean schedule still needs a clean handoff; see what belongs in a shift handover checklist.

Frequently asked questions

What is security scheduling?

Security scheduling is the process of assigning guards to shifts so every post is covered, letting guards request swaps, routing those swaps through manager approval and keeping the published roster checked against who is actually on site.

How is security scheduling different from a duty roster?

A duty roster is the output: the shift pattern and who’s assigned where. Security scheduling is the process that builds, publishes and maintains that roster, including how changes get requested and approved.

Can guards swap shifts themselves?

Guards can request a swap, but it should not take effect until a manager approves it. See the full process in a shift change request.

Does scheduling software replace a supervisor?

No. It replaces the spreadsheet and the unrecorded phone calls. A supervisor still approves swaps and makes the judgement calls; the system just gives that judgement a visible, auditable trail instead of relying on memory.

How do I know the schedule is actually being followed?

Compare it against attendance records rather than assuming the published roster and reality match. Geofence attendance confirms who was actually on site, against what the schedule said should happen.

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

See it on your own roster

AVES builds the schedule on a shared calendar, lets guards request swaps from their phone and routes every change through manager approval with a full audit trail, checked against real attendance, not assumptions. Book a 30-minute demo and we’ll show you the swap-approval screen a manager actually uses. Prefer to look around first? Start a free trial.

What is a toolbox talk? A toolbox talk is a short, focused pre-shift safety briefing, usually five to ten minutes, where a supervisor covers one specific hazard, recent incident or procedure with the guards going on duty. A toolbox talk template is the reusable structure that keeps these briefings consistent, so nothing important gets skipped and there is a record the talk actually happened.

The problem: talks that leave no trace

Most security sites run toolbox talks the same informal way: a supervisor gathers the outgoing or incoming shift, says a few words about “being careful out there,” and moves on. There is no fixed structure, no record of what was actually covered, and no way to check whether the same three guards missed the last four briefings.

When an incident happens later and a client or insurer asks whether guards were briefed on a hazard beforehand, a verbal-only toolbox talk gives a security company nothing to point to. The talk may well have happened, it just cannot be proven.

Why a structured toolbox talk template matters

A toolbox talk template solves three problems at once:

1. Consistency across sites. A guard company running several sites cannot rely on each supervisor remembering to cover the same ground. A template means a hazard review at Site A looks the same as at Site B.
2. An audit trail. Clients, auditors and insurers increasingly expect proof of routine safety communication, not just proof of training. A dated, topic-by-topic record answers that.
3. Faster onboarding. New supervisors can run a competent toolbox talk on day one if the structure is already written down, rather than improvising.

The 7-topic toolbox talk template

Use this as the running order for a pre-shift talk. Not every topic needs equal time, a two-minute mention is fine for anything that has not changed since yesterday.

1. Site-specific hazard of the day, the one thing most likely to cause harm on this shift (a broken light on a patrol route, ongoing construction, a slippery entrance after rain).
2. Weather or site conditions, anything that changes how guards should move or what they should wear or carry.
3. Recent incident or near-miss review, a short, blame-free recap of anything logged since the last talk, and what to watch for as a result.
4. PPE and equipment check, confirm the right kit (radio, torch, ID, any site-mandated PPE) is on hand and working.
5. Patrol route or checkpoint hazards, anything that has changed on the route since the last patrol (a blocked exit, a new checkpoint, restricted access).
6. Emergency procedure reminder, a rotating reminder of one procedure (evacuation point, code activation, who to call first) rather than repeating the full manual every time.
7. Open floor and acknowledgement, guards ask questions, and the supervisor notes who attended and confirms understanding.

What to record for every toolbox talk

A toolbox talk is only as good as its record. Capture at minimum:

• Date and shift
• Who delivered the talk
• Guards who attended
• The topic(s) covered that day
• Any question or concern raised
• Any follow-up item created, and its status until it is closed

Common mistakes that undermine toolbox talks

• Running the same generic talk every day. Guards switch off if the content never changes; rotate topics against the 7-point toolbox talk template above.
• No written record. A verbal-only talk cannot be produced later as evidence that a hazard was actually communicated.
• No follow-up close-out. A hazard raised in a talk and never checked again is worse than not raising it, it creates a paper trail showing the company knew and did not act.
• Treating it as a formality. A rushed thirty-second talk with no engagement satisfies nobody’s audit and does not actually change guard behaviour.
• No accountability for attendance. If a company cannot say who was in the room, it cannot show the guard on a later incident was actually briefed.

How AVES supports the record, honestly

AVES does not ship a canned library of toolbox talk scripts, that is not something to claim here. What AVES does ship is the record layer a toolbox talk template needs around the talk itself:

• The Daily Briefing module lets a supervisor log guard attendance by name, department and designation, a live property overview of site conditions, and a topic-and-description field for whatever was covered, exactly the structure a toolbox talk needs, timestamped and searchable later.
• Follow-up items raised during a talk go into the module’s follow-up field, tracked by status (pending, in progress, resolved) until someone closes them out, so a hazard mentioned once does not quietly disappear.
• The Security Meeting module can schedule a recurring toolbox-talk slot with attendance tracking, for sites that want it as a standing calendar entry rather than an ad-hoc gathering.

None of this writes the talk for a supervisor. It is the difference between saying a briefing happened and being able to show, by date and name, that it did.

Use this toolbox talk template at your next shift change

Print or paste the 7-topic toolbox talk template above into a supervisor’s handover pack, and run through it before every shift starts. A toolbox talk template only works if it is actually used, so keep it short enough that supervisors reach for it instead of skipping it. Most sites laminate a one-page version for the guard hut, then log the topic and any follow-up in Daily Briefing once the talk is done. Over a few weeks, this toolbox talk template becomes a habit rather than a chore, and the record it leaves behind is what turns a five-minute conversation into evidence a company can actually use.

Frequently asked questions

How long should a toolbox talk last?

Five to ten minutes is typical. Longer talks lose attention; the goal is one clear topic delivered well, not a lecture.

Who should run a toolbox talk?

Usually the shift supervisor or site lead, someone who knows the site’s current hazards and can answer questions on the spot.

How often should toolbox talks happen?

Most sites run one per shift change or at minimum daily. Higher-risk sites (construction-adjacent, night patrols, active incidents) often run them more frequently.

What is the difference between a toolbox talk and a daily briefing?

A daily briefing is the administrative record of a shift handover, attendance, site conditions, open items. A toolbox talk is the safety-focused conversation itself, usually a single topic. In practice, many sites log the toolbox talk topic and follow-up inside their daily briefing record rather than keeping two separate systems.

Can a toolbox talk replace formal safety training?

No. A toolbox talk reinforces and reminds; it does not substitute for the initial training a guard needs before starting a role.

Related reading

• Security Guard SOP: how to structure procedures guards actually follow
• Daily Briefing: the missing piece every security team overlooks
• Shift Handover Checklist: what every outgoing guard must log
• Church Security Checklist: 6 areas to cover
• Near Miss Report Form: 8 fields every report must include
• Security Guard Logbook

See it in action

Book a 30-minute demo and we will show you how Daily Briefing logs a toolbox talk’s topic, attendance and follow-up in one searchable record: Book a demo

Prefer to explore first? Start a free trial

Follow AVES on Instagram

A church security checklist is a structured list a place-of-worship security team works through before, during and after a service: entry points, safety equipment, patrol coverage and how an incident gets recorded. It turns “someone should check that” into a documented routine with a name and a timestamp behind every item.

Every church security checklist starts from the same reality: a church is an open building on purpose. Doors stay unlocked, strangers are welcome, and a service can draw more people through the door in two hours than most sites see in a week. That openness is the point, and it is also exactly what a security checklist has to work around. A checklist built for a warehouse or an office does not fit a sanctuary, a nursery wing, a car park that fills in fifteen minutes and empties in five.

This church security checklist guide sets out what a church security checklist should actually cover, the mistakes that turn a checklist into a box-ticking exercise nobody trusts, and how AVES gives a volunteer or contract security team a record they can point to afterwards, not just a form they filled in before the service started.

Why a church security checklist needs to be different

Most published “security checklists” are generic and built for a commercial site with controlled access: badge in, badge out, single entrance, no children on the premises. A church has none of that. Multiple entrances open at once for arrival. A nursery or children’s wing that needs its own check-in and check-out discipline. A car park and drop-off zone that is at its most dangerous in the ten minutes either side of the service. And a volunteer or part-time security presence that may not do this every day, which makes a written checklist more important, not less.

Skipping the church-specific detail means the checklist covers what the site does not need and misses what it does. A generic office checklist will tell a team to check the loading dock; it will not tell them to check that every children’s-area exit is staffed and every unfamiliar face near the nursery has been logged.

How a church security checklist works

The strongest version runs in three passes, tied to the rhythm of a service rather than a fixed clock.

Before the service. Walk every entry point, confirm which doors are staffed and which are locked, check the safety equipment that has to work if something goes wrong, and confirm the patrol or roving-officer assignment for the building and car park.

During the service. A roving presence covers the areas a fixed post cannot: car park, overflow seating, nursery corridor, foyer. Anything out of place gets logged as it happens rather than remembered afterwards.

After the service. A final sweep of the building, confirmation every checklist item was closed out (not just started), and a short handover note for whoever is on duty next time.

AVES supports this pattern through the Master Checklist builder, which lets a team define the exact fields a church site needs rather than being stuck with a generic template, combined with Patrol for the roving coverage and Incident forms for anything that needs a formal record.

The church security checklist: what to cover, section by section

Entry points and access

• Every entrance in use is identified and assigned a person, even if that person is also covering something else.
• Doors that should be locked during the service are confirmed locked, not assumed locked.
• Unfamiliar vehicles or visitors near side and rear entrances are noted, not just the main door.

Children’s and nursery areas

• Check-in and check-out discipline is confirmed working before doors open, not discovered broken mid-service.
• Every exit from the children’s wing is either staffed or alarmed for the duration.
• Anyone unfamiliar lingering near the nursery corridor is logged, whether or not anything comes of it.

Safety equipment

The six-system check AVES runs applies directly to a church building: emergency telephone, electro-magnetic door releases, emergency exit doors, intercom, panic button and radio. Each one gets a fault-to-review pass before the service: reported, actioned, reviewed, with a photo of the fault and the fix where one applies. A panic button nobody has tested since the building opened is not a safety measure, it is an assumption.

Patrol and roving coverage

A single fixed post at the main door cannot see the car park, the overflow room and the nursery corridor at once. AVES’s checkpoint patrol, with GPS-confirmed scans at each point and an optional selfie, gives a roving officer a route to actually walk rather than a vague instruction to “keep an eye on things,” and gives the team afterwards a record of where the officer was and when.

Car park and arrival/departure

• Drop-off and pickup zones are staffed at the two highest-risk windows: the ten minutes before the service starts and the ten minutes after it ends.
• Traffic flow is confirmed clear for an emergency vehicle at all times, not just checked once at the start.

Incident handling

If something happens, whether it is a medical event, a disturbance or an unauthorised person on site, it needs to go into a formal record, not a verbal note passed along after the fact. AVES’s incident forms capture six-sided photo and video evidence plus a written account, findings and next actions, so a church board or insurer asking “what actually happened” gets a real answer.

Common mistakes that make a church security checklist useless

Treating it as a one-time setup, not a routine. A checklist filled in once when the security programme launched, then never looked at again, tells you nothing about today’s service.

No record of who checked what, and when. A checklist with ticks but no name and no time attached cannot be trusted after the fact, which is exactly when it matters most.

Skipping the children’s area because it feels separate from “security.” The nursery corridor is one of the highest-consequence areas in the building and belongs on the same checklist as the main entrance, not a different one nobody reviews.

No equipment testing between incidents. A panic button or intercom that is assumed to work because it worked once is a liability, not a control. The fault-to-review loop exists precisely so equipment gets caught before it is needed, not after.

How AVES supports a church security checklist in practice

A church security checklist is only as good as the follow-through behind it. AVES does not replace the judgement of the person walking the building. It gives that person, and whoever reviews the record afterwards, a structure to work from and a trail to point to. The Master Checklist builder lets a church define exactly the fields this guide describes rather than adapting a commercial-site template. The six equipment checklists carry the fault-to-review record for safety systems. Patrol gives a roving officer a GPS-confirmed route through the building and car park instead of a vague instruction. Incident forms turn “something happened” into a documented, photo-backed account.

One honest note on scope: AVES records what a team checks, patrols and reports, tied to a named person and a timestamp. It is not a locksmith, an alarm-monitoring service or a substitute for trained security staff, it is the record that shows the checks actually happened.

FAQ

What should be on a church security checklist template?
Entry points and who is staffing them, children’s and nursery-area access, the safety equipment check (emergency phone, doors, intercom, panic button, radio), roving patrol coverage, car park and drop-off supervision, and a defined process for logging any incident.

How often should a church run its security checklist?
Every service, not just at setup. A before-service walk, a during-service roving pass and an after-service sweep is the pattern that catches problems while they are still small.

Who should be responsible for the checklist?
Whoever is leading the security team for that service, whether a volunteer coordinator, a contract security supervisor or church staff, with each section assigned to a named person rather than left open to whoever gets to it.

Does AVES provide church security guards?
No. AVES is a software platform that records checklists, patrols and incidents for a security team already on site. It supports whichever team, volunteer or contracted, is running your church’s security programme.

---

See the checklist and patrol trail on the real screen. Book a 30-minute AVES demo and we will walk through how a checklist, a patrol route and an incident record actually work together, with the real guard-app screens. Book a demo or start a free trial.

Related reading: Security Guard Audit Checklist · Equipment Inspection Checklist · Shift Handover Checklist · Digital Inspection Checklist · Incident Report Form · Security Guard Logbook. Follow AVES on Instagram.

Investigation report template: a structured document security teams use to record how a security investigation was conducted, what evidence was reviewed and who approved the findings, so the write-up holds up if it is challenged later.

A security investigation is only as strong as its paper trail. If a workplace theft, access breach or guest complaint ends up in a disciplinary hearing, an insurance claim or a legal dispute, the first thing anyone asks for is the investigation report. A vague summary email will not hold up. A structured template does.

Why a loose write-up fails

Security teams that skip a template tend to lose the same things every time: no record of which cameras or DVR footage were actually reviewed, no timestamp on when the investigation started versus when the incident happened, and no named sign-off showing who approved the conclusion. Without an investigation report template, six months later when someone asks “who looked into this and what did they find”, there is nothing but memory.

Investigation Report Template: What It Must Record

This investigation report template needs to cover the full chain from intake to sign-off, so the investigation report template is usable in a hearing rather than just a narrative paragraph.

• Case reference and date opened — a unique investigation ID and the date the case was logged, separate from the date of the underlying incident.
• Complainant / source intake — who raised it, how (verbal report, form, escalation from a guard), and their initial statement.
• Item or area under investigation — what was lost, damaged or breached, with location and time window.
• Evidence reviewed — DVR/monitor/camera review log: which cameras, which time ranges, what was seen. This is the section most loose write-ups skip entirely.
• Suspect / witness questioning — who was interviewed, when, and a summary of what they said.
• Supporting documents and images — attached evidence, photos of the affected item or area, any supporting paperwork.
• Findings — what the investigation concluded, stated plainly, separate from opinion.
• Approval sign-off — named approver, date and time, closing the case.

How AVES Supports an Investigation Report Template

AVES supports this investigation report template through two linked modules rather than a single free-text field. The Investigation Diary holds the working log: the investigation entry itself, a DVR/monitor/camera review record (which footage was checked and what it showed), and an approvedBy sign-off that closes the case with a name, date and time attached. The Lost Investigation module handles the intake side for loss-specific cases — complainant details, the item under investigation, suspect and witness questions and answers, and attached lost-item images or supporting documents.

Between the two, every section of the template above maps to a real field: intake, evidence review, questioning, supporting documents and sign-off are captured in the system rather than left to whoever wrote the email. Because entries are timestamped and the approval step is a discrete action, the finished record shows exactly when the case was opened, what was checked and who closed it — the three things a challenged investigation gets asked for first.

Common Mistakes With an Investigation Report Template

• Recording the conclusion but not the evidence trail. “Reviewed footage, nothing found” is not a review log — note the camera, the time range and what was actually visible.
• No separation between the complaint and the findings. Mixing what was reported with what was proven weakens the report if it is contested.
• Missing sign-off. An investigation without a named approver and closing date and time reads as unfinished, even if the work was done.
• Treating it as a one-off document. A template used inconsistently produces reports of wildly different quality — the value is in every case following the same structure.

FAQ

What should be in a security investigation report template?
Case reference, intake details, the area or item under investigation, an evidence review log (camera/DVR checks), witness and suspect questioning notes, supporting documents, findings, and a named approval sign-off with date and time.

How is an investigation report different from an incident report?
An incident report captures what happened at the time it happened. An investigation report documents the follow-up work — what was reviewed, who was questioned and what was concluded — and can be opened well after the original incident.

Who should approve an investigation report before it is closed?
A supervisor or manager with authority over the case, recorded with their name, date and time, so the closed case shows exactly who signed off.

Who needs an investigation report template

Any security team that handles theft, access breaches, guest complaints or internal disciplinary matters needs a repeatable investigation report template — not just large sites. A single warehouse with one security officer benefits just as much as a multi-site operation, because the moment a case is questioned, the question is never “did you investigate this” but “can you show me how”. A consistent investigation report template answers that question every time, regardless of site size.

Property managers, retail loss-prevention teams, facilities security and contract guarding companies all rely on the same underlying structure: an intake, an evidence trail, a questioning record and a named sign-off. The specific fields shift slightly by industry, but the investigation report template shape stays the same.

Investigation report template vs incident report: what’s the difference in practice

Teams often confuse the two. An incident report is filed at the time something happens — a break-in, an injury, a policy breach — and captures the immediate facts. An investigation report template is used afterwards, when someone needs to establish what actually occurred, who was involved and whether the initial account holds up. A single incident can generate one incident report and, if it escalates, a full investigation report built from that incident report plus camera review, witness statements and supporting evidence. Using an investigation report template only for genuinely investigated cases — not every minor incident — keeps the record meaningful instead of diluted.

Follow AVES Security on Instagram for more security operations tips.

---

Want to see how AVES structures investigation logging and evidence review for your team? Book a 30-minute demo and we’ll walk through the Investigation Diary and Lost Investigation modules on the actual screen. Prefer to look around first? Start a free trial.

Related reading: incident reporting software, incident report form: 8 fields every report must include, witness statement form, near miss report form, and for the daily record that feeds every investigation, the security guard logbook.