Category: Guard Management

Author: Kaviarasan, AVES Security content team. Last updated: 13 October 2026.

A security incident log template is the running register a site uses for every incident it records over time, not a single report. Where an incident report form captures one event in full, the log is the chronological list that lets a supervisor see every entry at a glance: what happened, when, who responded and whether it is closed.

Most sites already have an incident report form. What a lot of them are missing is the log that sits above it: the single page, book or sheet that lists every incident a site has had this month, in order, so a supervisor does not have to open twenty separate report files to answer “how many incidents did we have in March, and which ones are still open.” That list is the security incident log, and the columns it uses decide whether it is useful six months from now or just a pile of entries nobody can search.

This guide covers the eight columns a security incident log template needs, the mistakes that turn a log into a liability instead of a record and how AVES replaces the paper version with entries that cannot be rewritten after the fact.

Why a security incident log matters

A single incident report answers “what happened in this one case.” A log answers a different question: “what has been happening on this site.” Without one, a supervisor handing over to a new shift, briefing a client or preparing for an insurance review has to reconstruct a timeline from loose paperwork, which is slow and easy to get wrong. This is exactly the gap a security incident log template is built to close.

A proper log also protects the site when something is disputed later. If a client asks whether a particular type of incident has happened before or how many are still open, the answer should be a quick look down one list, not a search through a filing cabinet. And because a log is chronological, it surfaces patterns a single report never will, for example the same location showing up three times in a month, which is a sign worth acting on before it becomes a fourth incident.

How a security incident log works

The log itself is simple: one row per incident, added as it happens, never removed. Each row is a short summary, not the full case file. The detail, the photos, the findings, live in the incident report behind it. The log is the index; the report is the record.

That split in a security incident log template is what makes it fast to scan. A supervisor reviewing a week’s incidents should not have to read eight full reports to get a sense of what happened. They should be able to run down eight rows, spot the one marked still open and go straight to that report. A log that tries to hold the full narrative in every row stops being a log and becomes a duplicate of the report file, which defeats the point.

The 8 columns a security incident log template needs

These are the columns that keep a log useful rather than decorative, grounded in how AVES’s incident and safety modules already capture this information.

1. Date and time. When the incident happened, not when it was written up. AVES timestamps every incident, safety and defect entry at the point of submission, so the log reflects the real sequence of events.
2. Incident type. Whether the entry is a general incident, a security incident or a property/hotel-type event. AVES’s incident forms are split across these categories, which is what lets a log be filtered down to just one type when that is all a reviewer needs.
3. Location. Where it happened, specific enough to spot a pattern. A log that just says “on site” cannot tell you that the same loading dock has come up three times this quarter.
4. Short description. One or two lines, enough to know what kind of incident it was without opening the full report. This is the summary row, not the case file.
5. Evidence captured. Whether photo, video or audio evidence exists for the entry. AVES’s incident forms use a six-sided photo capture alongside video and audio, so the log can show at a glance which entries have supporting evidence and which do not.
6. Findings and action taken. What was done in response, even as a short note. AVES’s incident and defect/safety forms both carry a findings-and-actions field, which is what a log column should summarise rather than the signature line some paper sheets use instead.
7. Reported by and reviewed by. Who raised it and who signed it off. AVES ties every incident, safety report and investigation entry to a named reporter, and investigation-type entries carry a separate approvedBy reviewer, so responsibility for both the report and the review is on record.
8. Status, including whether a police report was filed. Open, under investigation or closed, plus a flag for cases that went to police. AVES’s incident forms carry a police-report field directly, so a log does not need a separate note to show which entries left the building.

Those eight columns are what turn a list of incidents into something a supervisor can actually use: a column for when, what kind, where, what happened, what evidence exists, what was done, who is accountable and where it stands now.

Common mistakes that make a security incident log useless

A security incident log template fails for a handful of predictable reasons. The most common mistake is no status column. Without one, every entry looks permanently unresolved, and a supervisor cannot tell an open case from one that was closed out weeks ago just by looking at the row.

The second is collapsing the log into the report. Some sites try to write the full narrative into every log row, which makes the log slow to scan and defeats its purpose. The log should point to the report, not replace it.

The third is no evidence flag. If a log cannot show which entries have supporting photo, video or audio evidence, a reviewer has to open every single report to find out, which is exactly the extra step a log is meant to save.

The fourth is a paper or shared-spreadsheet log that can be edited after the fact. A row that can be quietly changed is not a record, it is a draft. Entries need to be stamped with who logged them and when, and they need to stay that way once submitted.

How AVES supports the log, honestly

AVES does not ship a single standalone “incident log” screen separate from its incident, safety and investigation forms. What it does is capture every incident, defect and investigation entry as a timestamped, named record the moment it is submitted, through the six-sided photo and video and audio evidence capture, a findings-and-actions trail and a police-report field where relevant. Investigation-type entries add a separate approvedBy reviewer on top of the original reporter. That is what any security incident log template in AVES is actually built from.

That combination, taken together across a site’s incidents, is the log: a chronological, filterable list of every entry, each one backed by its own full report, with nothing in it that can be silently rewritten after submission. There is no signature-image field anywhere in AVES; sign-off is always a named accept, decline or submitted action with a date and time attached, which is a more searchable trail than a scrawl ever was.

FAQ

What is a security incident log template?

It is a running list of every incident a site records, one row per entry, covering when it happened, what kind it was, where, a short description, whether evidence exists, what was done, who is accountable and its current status. It sits above the full incident report rather than replacing it.

What is the difference between an incident log and an incident report?

A report captures one incident in full: the narrative, the evidence, the findings. A log is the index across every incident a site has had, built from short summary rows so a supervisor can scan a period at a glance.

How many columns should a security incident log have?

Eight is enough for most sites: date and time, incident type, location, short description, evidence flag, findings and action, reported by and reviewed by, plus status. Fewer than that and a log usually loses the ability to show what is still open.

Can a spreadsheet work as a security incident log?

It can for a single site with a low incident count, as long as someone actively maintains the status column. It breaks down once entries need to be tied to the original report, once more than one person edits it or once a client or an insurer needs a record that cannot be quietly altered after the fact.

Does AVES include a police-report field?

Yes. AVES’s incident forms carry a police-report field alongside the six-sided photo, video and audio evidence capture, so a security incident log template built from these entries can show which incidents went to police without a separate manual note.

Related reading

• Incident Reporting Software: how AVES captures incidents end to end
• Incident Report Form: the 8 fields every report must include
• Investigation Report Template: structuring a security investigation
• 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 AVES timestamps and ties together incident, safety and investigation entries so a log always reflects the real record behind it. Book a demo or start a free trial.

Internal links: Incident Reporting Software · Incident Report Form · Investigation Report Template · Near Miss Report Form · Security Guard Logbook. External: AVES on Instagram (DoFollow).

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).

Security companies run on equipment: CCTV units, two-way radios, body cameras, access-control hardware, patrol devices. Asset tagging software is what stops that equipment from becoming a spreadsheet nobody trusts. It gives every item a unique ID, so the business always knows where a piece of equipment is, who has it and what condition it is in.

Asset tagging software is a system that gives every physical asset, from CCTV units and radios to access-control hardware, a unique ID so it can be scanned, located and tracked through its entire working life: onboarding, placement, transfer, custody and retirement.

The problem with tracking security equipment on a spreadsheet

Most security companies start with a spreadsheet: one row per radio or camera, a column for who has it. It works for a month. Then a guard swaps sites. A supervisor hands a radio to a replacement without logging it. A stocktake turns up three missing units nobody can explain. The spreadsheet does not update itself when equipment moves. Nobody scans anything, so the record and the reality drift apart.

For a company running serialised equipment such as CCTV units and radios across multiple sites, that drift is not a minor annoyance. It shows up as lost equipment, disputed handovers and a stocktake that takes a full day of manual counting instead of an hour of scanning.

Why asset tagging matters for a security company

A security contract depends on equipment being where it is supposed to be. A missing radio during a shift is a safety gap, not just a cost. Asset tagging software closes that gap by tying every physical item to a record that updates every time the item moves, changes hands or changes status.

It also protects the business side of the relationship. When equipment is tagged and its location and custodian are logged, a dispute over a lost or damaged item has an audit trail behind it rather than a guess.

How asset tagging software works

Each asset is given a unique ID at onboarding, tagged with an organisation-specific asset-code prefix so items from different sites or clients are never confused. From that point, the asset’s ID is scanned during checklists, inspections and stocktakes and every scan adds to a history trail: where the item was, who scanned it and when.

When an asset needs to change hands or sites, the system runs the move as a request: a transfer is requested, authorised, then confirmed, rejected or cancelled, rather than simply being noted after the fact. A custodian can be assigned to an asset and released when it is handed back, so “who has this right now” is always a lookup, not a phone call.

7 things asset tagging software must do

1. Asset onboarding. New equipment is received into the system through a dedicated intake step, with an organisation-specific asset-code prefix applied so codes stay unique across sites and clients.
2. A unique, scannable ID per asset. Every asset carries one ID that is scanned during checklists and inspections, building a history trail instead of a one-off note.
3. Location placement. Each asset has a recorded location, so “which site is this radio actually at” is a lookup, not a guess.
4. Transfers between sites or organisations. Moving an asset is a workflow: request, authorise, then confirm, reject or cancel, so a transfer cannot happen silently.
5. Custodian assignment and release. An asset can be assigned to a named custodian and released when it is returned, keeping accountability with a person, not just a site.
6. Physical stocktakes by scanning. A stocktake is run by scanning assets to reconcile what is recorded against what is actually on site, rather than counting by hand.
7. Status changes, defect flagging and retirement. An asset’s status can be updated, a defect flagged against it and it can be retired from active use, with the change kept on its record. Asset data can also be exported for reporting.

Common mistakes when tagging security assets

• Tagging equipment but never scanning it again. A tag with no scanning discipline behind it is just a sticker. The value is in the history trail that builds up every time the asset is scanned during a checklist, inspection or stocktake.
• Letting transfers happen off the record. If a guard or supervisor can hand equipment to someone else without the system knowing, the custodian field stops meaning anything. Transfers need to go through request and authorisation, not a verbal handover.
• Treating a stocktake as an annual event. Scan-to-reconcile stocktakes are quick enough to run more often. Waiting a year to find out equipment is missing is waiting too long.
• Mixing asset codes across sites or clients. Without an organisation-specific prefix, the same-looking code can mean two different items at two different sites, which defeats the point of unique tagging.
• Not logging the custodian release. Assigning an asset to someone is only half the record. If it is not released when returned, the system still shows it as checked out.

Frequently asked questions

Is asset tagging software the same as an asset register?

No. A fixed asset register (see our fixed asset register guide) is primarily a financial record of what a company owns. Asset tagging software is operational: it tracks where each tagged item physically is, who holds it and its movement history, which then feeds into that register.

What counts as an asset worth tagging?

Serialised equipment that a security company issues and reissues is the clearest case: CCTV units, radios and similar hardware that need to be tracked individually rather than counted in bulk.

Does asset tagging cover a one-off equipment handover?

A single handover, such as issuing a radio for a shift, is better logged through a handover record (see our asset handover form guide). Asset tagging software is for the ongoing lifecycle of the asset across many handovers, transfers and stocktakes.

How does a stocktake actually work?

Assets are scanned against their recorded location, so the stocktake reconciles what should be on site with what is confirmed on site, flagging any mismatch instead of relying on a manual count.

What happens to an asset’s history when it is retired?

Retiring an asset updates its status rather than deleting its record, so the onboarding, transfer, custodian and inspection history stays available for later reference.

Where asset tagging fits in your wider security operations

Asset tagging software does not replace equipment handed out for a single shift (covered in our equipment sign out sheet guide) or the financial view of what the company owns (the fixed asset register). It sits alongside both, and alongside the wider platform described in our security guard management software overview, as the operational record for equipment that moves between people and sites. The same discipline of scanning and logging that works for assets is worth comparing with how AVES handles daily guard activity in the security guard logbook.

For product updates, follow AVES Security on Instagram.

If your business issues serialised equipment across more than one site, book a 30-minute demo and we will show you the actual asset tagging screen: onboarding, transfers and a scan-to-reconcile stocktake.

Book a demo or start a free trial.

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.