When a security agency gets a contract, the client does not hire guards. They hire posts — a gate post from 06:00 to 22:00, a control-room post around the clock, a lobby post during business hours. Each post must be staffed every shift, regardless of who shows up, who calls in sick, or what else is happening that day.
That distinction — post coverage versus headcount — is what makes running a security agency different from any other service business. And it is what most security agency management software does not actually address.
This article is for operations managers and owners of Indian security agencies with 50 to 500 guards across multiple client sites. It explains the three connected workflows — deployment, payroll, and billing — and what software needs to do for each one. It also covers what to ask before you buy a ready-made platform or commission custom development.
What the software needs to connect
The core problem is not scheduling guards. It is maintaining an unbroken chain from a contracted post obligation through to a verified pay record and an approved client invoice — especially when something goes wrong in between.
That chain looks like this:
Client contract → Post requirements → Roster → Actual duty → Approved record → Payroll calculation and separately → Client billing
The same underlying attendance events feed both payroll and billing, but the rules governing each are different. What a guard is owed as wages and what a client owes the agency for a post are separate calculations. Good software keeps them linked but not conflated.
Guard deployment: plan by post, not by person
Why a post-based view matters
An agency contracted to provide 10 guards at a manufacturing plant is not simply placing 10 people. It is covering a specific set of posts — main gate (24/7), visitor entry (6 AM–10 PM), production floor (3 shifts), parking area (6 AM–midnight). Each post has a required strength, a required rank, and a required shift pattern.
A headcount-only view of deployment cannot answer the question that matters every morning: are all contracted posts covered for today's shifts?
Software that only tracks who is rostered cannot flag that two guards are assigned to the same shift on the same post, that a post requires an armed supervisor and the person rostered does not have the required licence, or that a guard is coming off a night shift and is being rostered for a morning shift without the required rest period.
The reliever problem
When a guard assigned to a post cannot make their shift — sick leave, personal emergency, no-show — the agency needs a reliever. In practice this means the operations supervisor starts calling the float pool at 5 AM.
The reliever workflow creates several downstream problems that no off-the-shelf scheduling tool handles well:
- The reliever may already be working hours elsewhere that week. Deploying them again can trigger overtime.
- The reliever may not be cleared for that particular client site (background check not done, client-specific ID not issued).
- There is often a gap between when the original guard leaves and when the reliever arrives. That gap — even 30 minutes — is an uncovered post interval that the client may later deduct from the invoice.
- The handover itself needs to be recorded, not just the replacement guard's attendance.
A system that records a reliever as simply "replacement" on the attendance sheet loses all of this. Useful software preserves the original roster, the reason for absence, the replacement authorisation, the actual arrival time, and any uncovered interval separately.
Rotations, nights and the month-end boundary
A 24/7 post is not one shift. It requires at least three guards in rotation, with weekly offs, rest periods, and shift handovers. Configuring a rotation schedule that keeps every post covered while respecting legal rest requirements and managing individual preferences is a non-trivial planning problem.
Night duty that starts on the 30th of the month and ends on the 1st of the next month is a date-attribution problem that trips up every spreadsheet-based agency. The hours must be split correctly between payroll periods. The billing must attribute the shift to the right invoice month. If a public holiday falls in the middle, the applicable rate may change partway through.
A date-only attendance system — one that records only which day the guard worked, not the start and end times with timezone-correct timestamps — cannot correctly handle any of this.
Payroll: what makes a security agency's payroll different
Multiple sites, multiple rate structures, one employee
A guard who works 12 days at Site A and 8 days at Site B in the same month has one employment record but two sets of deployment data. The wages for each assignment may differ — Site B may have a higher site allowance, or a different shift pattern. The cost must be allocated to the right client in the agency's books.
The approach of creating a new payroll record per deployment — treating the guard as effectively a different person at each site — causes statutory problems. PF and ESIC contribution history is tracked against the employee's UAN and IP number, not against a site. Fragment the employment record and the contribution history breaks, creating reconciliation problems during inspections and at the time of claims.
The correct approach: one employee identity with dated deployment records. Payroll is calculated for the employing entity. Cost allocation happens as a reporting layer.
PF, ESIC and principal employer liability
Under the Contract Labour (Regulation and Abolition) Act, 1970, when an agency deploys workers on a client site, the client becomes the principal employer for those workers. If the agency defaults on PF or ESIC contributions, the principal employer is liable.
This is why serious enterprise clients — manufacturing plants, IT parks, government facilities — require monthly compliance certificates from their security agencies. They need confirmation, not just assurance, that PF and ESIC contributions have been deposited for the guards working on their premises.
Software that generates site-wise ECR reports and ESIC challan summaries — allowing the agency to provide per-client statutory evidence — is addressing a real commercial requirement, not just an internal accounting convenience.
The Labour Code transition (effective November 2025)
The four Labour Codes came into force from 21 November 2025. For security agencies, the relevant changes include:
- Wage structure: The Code on Wages establishes that components designated as wages cannot be structured below 50 percent of total CTC for the purpose of PF computation. Agencies that had restructured compensation to minimise PF liability need to review their pay structures.
- Fixed-term employment and gratuity: Under the Code on Social Security, fixed-term employees become eligible for gratuity after one year of service rather than five. Security agencies commonly use rolling annual contracts for guards; this change has a direct cost implication.
- Overtime cap: Draft rules under the OSH Code propose a quarterly overtime cap of 125 hours. The rules were not in final Gazette notification form as of this article's publication date — verify the current position before making any commitment in client proposals or contracts.
These changes are not yet reflected in most agency software or payroll tools. A system built or configured before November 2025 may be computing PF on a wage basis that is no longer compliant.
Advances, arrears and final settlement
Advance payments to guards — particularly around festivals — are common in the sector. Recovery of advances through salary deductions over subsequent months creates payroll complexity that generic HR software handles poorly, especially when a guard leaves before the advance is fully recovered.
Final settlement for a departing guard must account for: unpaid wages, any outstanding advance recovery, leave encashment, uniform or equipment deposits, and any applicable gratuity. If the guard was provided accommodation or transport by the agency, those recoveries must be handled within the limits that wage law permits — not every deduction that an agency might want to make is lawful.
Client billing: why payroll totals do not equal billable amounts
Post-based billing versus hour-based billing
Client contracts in the Indian security sector use different billing units depending on the client type. Government and large enterprise clients often use a monthly rate per post per shift — the agency bills for the post being covered, not for the individual guard. Smaller commercial clients may use a man-day or man-hour structure.
The billing structure matters because:
- A post-based contract does not automatically bill more when the agency deploys a reliever to cover an absence. It bills for post coverage. A prolonged uncovered interval may result in a shortage deduction.
- A man-day contract bills for every guard deployed, which means a reliever adds to the billable total — but only if the client accepts and signs off on the replacement.
- An extra-duty assignment — deploying an additional guard for a special event — requires pre-approval and is billed at a separately agreed rate or at the standard rate with a written order reference.
Software that produces a billing report by simply counting attendance records cannot distinguish between these cases correctly.
Client muster reconciliation
At the end of every billing month, the agency prepares an invoice. The client's premises manager has their own attendance register — a muster maintained at the gate or the admin office. The two records rarely match perfectly.
A guard who took an hour's personal break, a weekend with reduced deployment that the operations team didn't log correctly, a replacement guard whose ID the client admin didn't record — any of these creates a discrepancy. The client may raise deductions against the invoice.
The reconciliation workflow — comparing the agency's attendance records against the client's accepted muster, identifying and resolving discrepancies, and agreeing on any shortage adjustments before the invoice is finalised — is where cash flow problems in security agencies typically originate. It is also the workflow that is almost entirely absent from security software reviews and product marketing pages.
Useful software provides: a locked version of the agency-side attendance record, a facility to record the client's acceptance or deductions, a comparison that surfaces discrepancies rather than assuming the agency's records are final, and an audit trail that preserves both versions.
Disputed invoices and month-end corrections
When a client disputes part of an invoice after it has been raised — or when a guard's attendance is corrected after payroll has been approved — the system needs to handle the correction without silently rewriting history.
The payroll run has already been locked. The wages have been paid. What needs to happen is: a billing adjustment (credit note or revised invoice), with an audit trail that shows what changed, who approved it, and when. The original payroll should not be retroactively altered. If there is a carry-forward adjustment to the next month, it should be explicit and signed off.
Compliance: PSARA, Form X, and document management
PSARA is state-level, not national
The Private Security Agencies (Regulation) Act, 2005 is administered at the state level. An agency operating across Tamil Nadu, Karnataka, and Maharashtra needs a separate licence for each state. The applicable rules — including the specific register formats, supervision ratios, and verification requirements — differ between states that have adopted the Central Model Rules and states that have notified their own versions.
Central Model Rules 2020 specify Form X as the electronic register that agencies must maintain. Form X covers: agency and supervisor details, guard personnel records, client information, service locations, and duty rosters. An agency that maintains Form X accurately in an integrated system is inspection-ready. One that maintains it separately from operational data — or reconstructs it manually before inspections — is carrying continuous compliance risk.
A note on Form F: Form F is sometimes mentioned in the context of security agency compliance. Form F is actually the gratuity nomination form under Rule 6 of the Payment of Gratuity (Central) Rules, 1972. It is not a PSARA register. The applicable PSARA register under the Central Model Rules is Form X.
Personnel documents and deployment eligibility
Before deploying a guard to a client site, an agency must have on file: the police verification certificate, the training completion certificate, a medical fitness certificate (renewed annually), the photo ID card, and any client-specific clearances.
Software that manages deployment eligibility — blocking a guard's roster assignment if a required document is expired or missing — turns a compliance requirement into an operational control rather than a post-inspection finding.
Contractor mapping for PF and ESIC
ESIC's contractor-mapping system requires that insured persons working under a contractor (the security agency) are linked to the principal employer (the client site) in the ESIC system. EPFO similarly requires that contractor workers' UAN records reflect the actual employing entity and the contributions made for them.
When a guard moves between client sites during the year, the statutory history should follow the employee — not be fragmented across site-specific records. Software that maintains this linkage correctly reduces the reconciliation burden at year-end and at the time of employee claims.
What to ask a vendor before buying
The questions below are useful regardless of whether you are evaluating a specialist platform, a generic HRMS with a security industry page, or a custom development proposal. Ask for a live demonstration of each, not a screenshot.
- One post, two guards sharing the duty in sequence: does the system show both pay records without billing the post twice?
- A guard is replaced 30 minutes after their shift should have started: is the uncovered interval visible in the post coverage report after the shift is marked complete?
- A night shift starts on the 30th and ends on the 1st: does the system retain the original timestamps, and can it split hours across payroll periods with an explicit attribution rule?
- A guard moves from Site A to Site B mid-month with different site allowances: can the system explain the month's earnings per site without creating a second employment record?
- A client rejects two days of a guard's attendance after payroll has been approved: can finance adjust the invoice without altering the approved payroll?
- An offline attendance sync arrives after payroll is locked: is there a reviewable correction workflow rather than a silent rewrite of historical records?
- Can the system produce a site-wise PF/ESIC contribution summary for each principal employer client?
- Can a client-portal user see only their own site's approved attendance and reports, with no access to payroll data or other clients' information?
Ready-made platform, integration, or custom development?
There are capable specialist platforms in this space. ZeniaHR, eBLACKDOG Payroll, INDPayroll, and Tainaat WorkforceOS each address parts of the problem described in this article. Tainaat in particular covers a wide operational scope — deployment, biometric attendance, roster gaps, compliance rules, payroll, and GST invoicing. Evaluate these seriously before assuming custom development is necessary.
The decision framework is not how many guards you have. It is:
Choose a ready-made platform when: the platform can be configured to your specific shift structures, your billing model, and your compliance requirements; it has usable data exports so you are not permanently dependent on the vendor; it has reliable support and a realistic update commitment for regulatory changes; and the total cost of ownership — including licensing, onboarding, and ongoing support — fits your margin structure.
Consider integration when: payroll already works in a system your team trusts, but deployment and billing data do not flow into it cleanly. The integration problem is often smaller than it appears, and it avoids duplicating data in two separate systems.
Custom development becomes a candidate when: there are important, verified workflow gaps — reliever management, post-based billing, site-wise statutory reporting — that the platforms you have evaluated cannot address through configuration; the business case covers not just development but ongoing maintenance and regulatory updates; and the agency has the internal discipline to document its own processes clearly enough to specify what it needs built.
Guard count alone does not make the decision.
How Raaxo approaches this kind of software
Raaxo Technologies has not built security agency management software. We have built an operational ERP for Easy Facility Services, a facility management company, that handles attendance, payroll, client billing, and statutory compliance across multiple sites. The structural problems — post coverage planning, multi-site payroll, principal-employer compliance, client-wise billing reconciliation — are similar.
What we bring to this kind of project is the ability to model your actual workflow before writing a line of code: the post requirements, the reliever pool logic, the billing rules per client, the PF/ESIC evidence trail. If your process has edge cases that a generic platform handles poorly, we can build around them rather than asking you to work around the software.
If you are evaluating whether custom development makes sense for your agency, bring a redacted roster, a payslip, and a disputed invoice to the conversation. That is usually enough to identify where a generic system would break for you — and whether what you need to build is narrower than you think.
Talk to us about your requirements →
Frequently asked questions
How is post coverage different from attendance? Attendance records which guards were present and when. Post coverage records whether each contracted post was staffed through its required interval. A site can have full attendance — every scheduled guard signed in — while still having uncovered post intervals if rosters were misaligned or handovers failed.
How should relievers be recorded in the system? A reliever deployment should create a record that links to the original roster assignment, the reason for absence, the authorising supervisor, the actual arrival and departure times, and any gap between the original guard's departure and the reliever's arrival. The reliever's attendance is separate from the original guard's and feeds their own payroll record — not the original guard's.
Can one guard work at several client sites in a month? Yes, and this is common. The guard should have one employment record and one payroll calculation for the month. Their earnings, allowances, and statutory deductions are consolidated. Site cost allocation is handled separately in the agency's accounts. Creating separate employment records per site fragments the statutory contribution history.
Does night duty automatically mean overtime? Not automatically. Night duty may attract a night shift allowance under the terms of the employment contract or a collective bargaining agreement. Overtime applies when total hours worked exceed the legal limit — typically 48 hours per week under most applicable rules — regardless of whether those hours are during the day or night. The two are often confused. Verify the applicable rules for your state and employment category; the Labour Codes have changed some thresholds.
Can client billing differ from payroll totals? Yes, and this is normal. A client billed per post per month owes a fixed contracted amount regardless of how many guards the agency used to staff that post. A guard who covered two posts in one shift is paid for the hours worked; the billing is determined by which posts were covered and what the client's rate card specifies for each.
Does software make an agency PSARA-compliant? Software can help maintain the records that PSARA requires — Form X, personnel documents, duty rosters, client site records — and flag expiring licences and documents before they become inspection findings. Compliance itself remains the agency's legal responsibility. A well-maintained system is an aid to compliance; it does not substitute for it.
When does custom development make sense over a ready-made platform? When you have evaluated specialist platforms and found that important parts of your workflow — reliever management, post-based billing, site-wise statutory reporting — cannot be handled through configuration; and when the cost of custom development (including ongoing maintenance and regulatory updates) is justified by the workflow gain. Start by identifying the specific cases that break in the platforms you have reviewed.
Raaxo Technologies builds custom software and ERP systems for operations-intensive businesses. Our work in facility management software and client billing systems gives us direct experience with the multi-site, multi-client payroll and billing problems that security agencies face. For a workflow discussion, book a call or get in touch.
A post coverage view separates contracted obligations from individual attendance — the gap between the two is where billing disputes and compliance risks originate.
The same approved duty record branches into payroll (governed by wage rules and statutory obligations) and client billing (governed by the commercial contract). They must stay linked but are calculated separately.