Every security company runs on the same document. It is the timesheet a record per post, a line per guard, hours in and hours out, signed off by a supervisor or captured on a phone at the gate. Everything the business bills and everything it pays out starts there.
And in almost every company we have worked with, that one timesheet gets keyed in twice. Once into whatever produces the client invoice. Once into whatever runs payroll. The two are supposed to agree. They never quite do, and somebody spends the first week of every month finding out why.
If you are planning to build software for this or buy it the feature list is the easy part. Scheduling, time and attendance, payroll, billing, compliance, reports. Every vendor has that list. What is worth understanding first is where the money leaks between the timesheet and payday, because that is what the software has to stop. Here are seven places, in roughly the order they will find you.
| Why is payroll harder for a security guard company than for an ordinary business? |
|---|
The timesheet is the invoice and the paycheck, and it gets keyed in twice
Start with the shape of the problem, because everything else follows from it.
A guard works a twelve-hour shift at a client's distribution center. That shift is worth one amount to the client the bill rate in the contract, per hour, per post and a different amount to the guard, at their pay rate, before taxes and deductions. Same shift, same person, two numbers, two documents.
The time sheet is the only source for both. So, operations keys it into the billing spreadsheet, and whoever runs payroll keys it into the payroll system, and somewhere between the two a night shift becomes a day shift, a fill-in gets counted on one side and not the other, or an 11.5 becomes an 11. Neither record is wrong on its own terms. They are no longer describing the same week.
Here is what makes it expensive rather than annoying. If the billing is short, you underbill the client and never hear about it nobody calls to say they were charged too little. If the payroll side is long, you overpay a guard and never hear about that either. Errors in this system are silent in exactly one direction each, and both directions cost you money.
On the security company management platform we built, time is captured once, against a guard's assignment to a post, and both the invoice and the payroll are generated from that single record. That is not a feature. It is the whole architectural decision, and every one of the next six problems is easier because of it.
The pay period and the billing period are not the same period
Guards are paid weekly or every two weeks. Clients are billed monthly, usually on net 30. Overtime is calculated during the workweek. Three different calendars, one set of hours.
A bi-weekly pay period that starts on the 27th and ends on the 10th contains hours for two different invoices. A monthly invoice contains hours from two or three different paychecks. When the numbers do not reconcile and they will not be, nobody can say which period the difference belongs to, because the periods overlap and the spreadsheets were built around one of them.
Then there is the shift itself. The contract says eight hours per post per day. The post runs twelve, because that is how security works, and the invoice has been quietly rounding that for three years. Or the contract says twelve and the guard regularly does sixteen because relief did not show, in which case somebody is owed overtime and somebody else should be billed for it, and the timesheet does not say which.
What the software must hold is a billing basis per contract hourly, per post per day, or flat with the shift length, holiday treatment and fill-in rules attached to the client, and a pay period per guard that is independent of it. Hours are the atom. Invoices and paychecks are two different ways of adding them up, and both must be able to cut across each other's boundaries without a human doing it in a spreadsheet.
Overtime you must pay but cannot pay bills.
This is the problem that costs US security companies the most money, and it comes from a mismatch that is easy to state and hard to manage.
Under the Fair Labor Standards Act, a non-exempt employee must be paid at least one and a half times their regular rate for every hour beyond forty in a workweek. Security officers are, with very few exceptions, non-exempt. And overtime is calculated across everything the guard worked that week — every post, every client, every fill-in.
Each client contract, on the other hand, only sees its own post. Client A's contract covers Client A's hours at Client A's bill rate. It does not know, and does not care, that the same guard covered an open post at Client B on Friday night and crossed forty hours doing it. The company owes the overtime premium. Neither contract says the client will pay it. The difference comes out of the margin, and it comes out silently, because the scheduler who filled the open post was solving a coverage problem, not a payroll one.
Some states go further. California, for instance, applies daily overtime beyond eight hours in a day as well as weekly overtime beyond forty, which means a single twelve-hour post generates premium pay every shift regardless of what else the guard worked. The rule that applies depends on where the post is, not where the company is headquartered.
The fix is not a payroll fix. It is a scheduling fix: the system has to see the guard's whole week across every site before it lets a scheduler assign one more shift, and it has to show the cost of that assignment at the overtime rate, against the bill rate of the post being filled at the moment the decision is made. A company that only discovers unbillable overtime when payroll runs has already paid for it.
The rate depends on the state, the city, and whether the client is the government
The federal minimum wage is $7.25 an hour and has been in charge since 2009. Almost nobody in security is paid for it, because most states — and a growing number of cities and counties set their own higher minimums, and those change on their own schedules, often every January. A company with posts in two states, or in a city with its own ordinance, is running several wage floors at once, and a guard who transfers between them changes floor with the transfer.
Federal contracts add another layer. Under the Service Contract Act, security services on covered federal contracts have to be paid the prevailing wage and fringe benefits set out in the wage determination attached to that contract which is specific to the contract, the location and the occupation, and is different from whatever the same guard earns on a commercial post across the street. The health and welfare component must be either paid in cash or provided as benefits, and the paperwork that proves it was part of the contract.
So, the rate for a shift is a function of at least four things: the state, the locality, the contract type, and the effective date. A spreadsheet holds one pay rate per guard. The system must hold a key rate on all four, with effective dates, and resolve the correct rate from the assignment not from the guard's profile, and not from whatever someone remembered when they set up the row.
Payroll taxes sit alongside this federal and state withholding, Social Security and Medicare, federal and state unemployment, workers' compensation at the rate for security work in that state and every one of them has a rate or a wage base that moves annually. The design point is the one that does not move: those numbers belong in one place, with effective dates, and every calculation reads them from there. When a rate changes, you change one row, not four hundred cells. This is a description of what the software has to handle, not tax advice take advice on your own position.
A guard with a lapsed license is a liability you cannot bill for
Security guard licensing in the United States is set state by state. California issues a guard card through its Bureau of Security and Investigative Services. Florida issues a Class D license. Other states have their own registration, training-hour and renewal requirements, and armed guards carry a separate permit on top. A guard whose license has expired cannot lawfully be on post, and a company that puts one there has a compliance problem, a client contract problem and, if anything goes wrong on that shift, an insurance problem.
In most companies the license lives in a filing cabinet or a spreadsheet column, and the person doing the scheduling is not the person tracking renewals. The failure is quiet: a guard who has been in the same post for two years keeps being scheduled after their card lapses, because nothing in the scheduling process asks.
Licensing therefore belongs to scheduling, not in HR. The license number, type and expiry date sit on the guard's record; the scheduler refuses to assign a guard whose license has expired or will expire during the assignment; and renewals surface thirty or sixty days out, to the guard and to the office, rather than the morning of the shift. The same mechanism handles the client-specific requirements a hospital that needs a particular certification, a federal site that needs a background check on file because those are just more expiring credentials attached to a post.
Hours are re-keyed by the payroll provider, and the wrong digit pays the wrong guard
At the end of all of this is an upload. Most security companies run payroll through a provider — or through their bank's direct deposit — which means the approved hours and earnings have to leave the scheduling system and arrive in the payroll system in the provider's format, one row per guard, with the right earnings codes for regular time, overtime, differentials and deductions.
In most companies that file is built by hand: hours copied from one screen into another or exported from scheduling and massaged in a spreadsheet until the import stops rejecting it. That is one more re-keying step, and it is the one with the least room for error. A transposed digit in an hour’s column breaks the reconciliation and takes a morning to find. A guard mapped to the wrong employee ID pays the wrong person and recovering that money is a conversation nobody wants to have.
The fix is boring and absolute. The payroll file is generated from the approved timesheet, in the provider's exact import format, and the total on the file is asserted equal to the total on the approved payroll run before it can be downloaded. On the platform we built, the export cannot be produced from anything other than the approved run, which means the number that goes to the provider is the number the system says went to the provider.
Uniforms and equipment are money too
A guard is issued a uniform, a badge, a belt, a radio, sometimes a flashlight and a jacket. Each has a cost, some are recoverable through a deduction or a deposit, and all of them are supposed to come back when the guard leaves. In practice the issue log lives in a closet, deductions are applied from memory, and what comes back at separation is negotiated.
There is a legal edge to this in the US that a spreadsheet will not catch: under federal wage rules, the cost of a required uniform cannot bring a worker's pay below the minimum wage for the week or cut into overtime pay. A deduction that is fine for a full-time guard at a comfortable rate can be unlawful for a part-timer who worked twelve hours that week. Whether a deduction is allowed depends on that week's hours and that week's wage floor — which is problem 4 again, wearing a different jacket.
So, issues and return are recorded against the individual, the deduction schedule flows into payroll automatically, the payroll run checks each deduction against that period's minimum wage before applying it, and the separation process knows what is outstanding before the final check is calculated. It is inventory, but it is also payroll and compliance and treating it as a separate spreadsheet is how it ends up in none of them.
Underneath all seven: guards are paid every two weeks, clients pay in sixty days
None of the problems above are the reason security companies run out of money. The reason is that pay rises every one or two weeks and client payment terms run thirty, forty-five or sixty days from the invoice so the company funds every pay period out of its own pocket and waits to be reimbursed. A company growing quickly is the one most likely to feel this, because every new contract is another month or two of payroll it must float.
That gap cannot be engineered away. What software can do is stop making it worse. Every day the invoice is delayed because timesheets are being reconciled is a day added to the gap. Every under-billed shift is money that never arrives to close it. Every dollar of unbillable overtime widens it. And a company that cannot show a client a clean, itemized, timesheet-backed invoice on the first of the month is a company whose invoices get questioned, and a questioned invoice is a net-30 that quietly becomes net-75.
Fast, correct invoicing is not an operations nicety for a security company. It is the cash flow.
What we built, in brief
We built a management platform for a security and manpower company that starts from the principle in problem 1 and follows it through. Time is captured once, against a dated assignment of a guard to a post, and everything else is computed from it.
Client contracts carry their own billing basis, shift length and fill-in and overtime rules, so each client's invoice is generated at that client's terms without anyone re-deriving them. Pay rates sit in a table keyed on location, category and effective date rather than on the guard's profile, and the statutory layer — built for that client's jurisdiction — sits in the same kind of table, so a rate change is one edit rather than a hunt through cells. Uniform and equipment issues, deductions and returns are recorded against the guard and flow into payroll and final settlement automatically. Employee onboarding, with the documents the company must hold on file, sits at the front of it. The payroll file is produced only from an approved run, in the required format, and checked against the run total before it can be downloaded.
That client was not in the United States, so the rules in its statutory table are not the rules above. The architecture is what transfers. A US deployment puts federal, state and local wage floors, workweek overtime with any daily rules, Service Contract Act determinations where they apply, payroll tax parameters and license expiry dates into that same table — and points the scheduler at it, so the overtime and licensing checks in problems 3 and 5 happen before an assignment is confirmed rather than after payroll runs.
It is built in Python and Django with a React front end and PostgreSQL. The full breakdown, including the modules and the reasoning behind the data model, is on the project page: security company management software.
A checklist before you build or buy
Take this to the first conversation with a vendor or a development team. The third column is the one that matters.
| Problem | What it costs if ignored | What the software must do |
|---|---|---|
| Timesheet keyed twice | Silent under-billing and over-payment, every period | Capture once; generate invoice and payroll from the same record |
| Pay period vs billing period | Reconciliation that never closes | Hours as the atom; invoices and paychecks cut across each other's boundaries |
| Unbillable overtime | Premium pay out of margin, every week | Scheduler sees the guard's whole week across all sites, shows OT cost before assigning |
| Rate by state, city, contract | Wage-floor violations, mispriced contracts | Rate table keyed on location, contract type and effective date |
| Lapsed licenses | Guard on post unlawfully; insurance exposure | License expiry on the record; scheduler blocks expired or expiring guards |
| Payroll file re-keyed | Wrong hours, wrong recipients | Generate from approved run in provider format; assert totals match |
| Uniforms and equipment | Unrecovered costs; unlawful deductions | Issue, deduction and return per guard; deduction checked against that week's wage floor |
FAQS
Why is payroll harder for a security guard company than for an ordinary business?
Because the same timesheet has to produce two different numbers. Every hour a guard works is billed to a client at a contract rate and paid to the guard at a wage rate, with overtime, differentials, licensing rules and mid-week post changes applied differently on each side. In most companies that one timesheet is keyed into a billing spreadsheet and a payroll system by two different people, and the moment they diverge the company is either under-billing a client or over-paying a guard without knowing which.
Why do security companies end up with overtime they cannot bill?
Federal law requires non-exempt employees to be paid at least one and a half times their regular rate for hours beyond forty in a workweek, and most guards are non-exempt. Overtime is calculated across everything a guard worked that week, but each client contract only sees its own post. So a guard who covers an open post at a second site on Friday crosses forty hours, the company owes the premium, and neither client's contract says they will pay it. Scheduling and billing have to see the guard's whole week, not one site at a time.
What should security company payroll software calculate automatically?
From a single timesheet it should produce the client invoice at each contract's bill rate and billing period, the guard's gross pay at the correct rate for the state, city and contract type, overtime across the whole workweek, shift and holiday differentials, uniform and equipment deductions within legal limits, and a payroll export in the payroll provider's or bank's format that reconciles to the cent. Anything a person re-keys between those steps is where the errors live.
How should a security company track guard licenses and certifications?
As part of scheduling, not as a filing exercise. Guard licensing is set state by state, each with its own registration, training and renewal requirements, and a guard whose license has lapsed cannot lawfully be on post. The license number and expiry date should be held on the guard's record, the scheduler should refuse to assign a guard whose license has expired or will expire during the assignment, and renewals should surface weeks ahead rather than the morning of the shift.
How do you handle a guard who works at two client sites in the same pay period?
Record the deployment as a dated assignment rather than a field on the guard's profile. A guard at a distribution center Monday to Wednesday and a hospital Thursday and Friday generates two invoice lines to two clients at two bill rates, possibly two pay rates if the sites carry different contract terms, and one overtime calculation across both. A spreadsheet with one rate per guard cannot represent that, which is why multi-site guards are where manual payroll most often goes wrong.
Can Fly IT Solution build payroll and invoicing software for a US security company?
Yes. We built a complete management platform for a security and manpower company covering employee onboarding, attendance-based payroll, client-specific pricing and invoicing, statutory calculations for that client's jurisdiction, payroll file generation and uniform and equipment inventory, in Python and Django with a React front end. The same architecture - one timesheet, rate rules in one table with effective dates, payroll exported rather than re-keyed - is what a US deployment needs, with federal, state and local rules and license expiry in that table instead. We work with North American operators from Minneapolis.
Closing
None of the seven is exotic. Every one of them is a consequence of one timesheet being keyed in twice, and every one of them is cheaper to design out than to reconcile every pay period for the life of the business.
If you run a security company and the first week of the month still means two people comparing spreadsheets or your overtime line keeps surprising you we are happy to look at how your hours actually flow from the post to the paycheck, before you decide whether to build, buy, or keep the spreadsheets. We do this work for North American operators from our office in Minneapolis, Minnesota.
On the regulatory references. The federal overtime rule and minimum wage are stated as they stand under the Fair Labor Standards Act; the Service Contract Act, state licensing and uniform deduction rules are described by structure rather than with figures, because state rates, training hours and wage determinations change and a printed number dates quickly. None of this is legal or tax advice; take advice on your own company's position.
