Extract ADT & Securitas Invoices to Excel for Multi-Site AP

A multi-site security invoice from a vendor such as ADT Commercial, Securitas Technology, or Allied Universal mixes two kinds of charges: flat recurring per-site monitoring, and irregular exceptions like service calls, false-alarm fees, fire-system inspections, and guard post-hours. Each charge needs its own GL code, its own cost centre, and a tag identifying the site it belongs to. To get a multi-site security invoice to Excel cleanly, extract one row per line item with the site or store number repeated on every row, and keep the recurring charges and the variable exceptions in separate columns so each can be allocated and coded independently. The result is a per-site spreadsheet that supports cost allocation, false-alarm chargebacks, and a roll-up to portfolio-wide security spend.

The difficulty is scale and shape, not any one charge. A single consolidated PDF can run dozens of pages and cover anywhere from 50 to 500 or more sites every month, with fire-inspection and guard-hour cycles layered on at their own intervals. It is a recurring batch job, not a one-off lookup. The store-level monitoring fee is predictable; the false-alarm fee passed through from a city ordinance, the after-hours dispatch when a panel went into trouble, and the quarterly guard-hour summary are not, and those are the lines that need the most careful handling.

One thing to be clear about up front: this is commercial security billing. ADT Commercial, Securitas Technology, Allied Universal, Johnson Controls, and their peers bill multi-site contracts to retail chains, REIT and property-management portfolios, and bank-branch networks. That is a different document and a different billing relationship from residential single-home alarm service. If you are coding a consolidated invoice covering your whole portfolio of stores or properties, you are in the right place.

The Line-Item Taxonomy and the GL Account Each Charge Maps To

A consolidated commercial security invoice carries a fairly stable set of charge types, even when the layout differs from vendor to vendor. Knowing the full list lets you build a chart-of-accounts mapping once and reuse it every month. Here is what shows up, and how each charge is normally classified for posting.

Recurring monitoring fee. The per-site, monthly flat charge for central-station intrusion monitoring. This is the largest and most predictable line, and on most invoices it repeats once per site. It posts to a recurring security-monitoring expense account, allocated by site.

Cellular or radio backup fee. A separate monthly charge, billed per panel, for the dual-path or cellular communication path that backs up (or has replaced) the old phone-line connection. It rides alongside the monitoring fee and is one of the most frequently missed recurring add-ons, because it looks like part of the monitoring line but is billed separately. It posts with monitoring as recurring operating expense.

Fire-alarm monitoring. Central-station monitoring of the fire system, billed separately from intrusion monitoring even when both are on the same panel. It often maps to a different GL account from intrusion, partly because fire monitoring is mandated rather than elective.

Video and access-control services. Where the vendor hosts them: video or VMS monitoring, and hosted access control rated per door, per month, so a site with twelve controlled doors carries twelve units on that line. These are recurring operating charges, often coded to their own subaccounts.

Equipment lease and recurring equipment charges. Keypads, panels, cameras, and similar hardware billed as a recurring monthly charge rather than a capital purchase. This is the RMR (recurring monthly revenue) the industry runs on, and from the customer side it is recurring equipment expense or a lease line, depending on contract structure.

NFPA 72 fire-system inspection. Periodic inspection and testing of the fire system, billed annually or semi-annually per site under the NFPA 72 cycle. This is not a monthly charge and frequently does not belong in monthly expense at all, which is why it gets its own section later in this article.

Service-call dispatch. When a site has an alarm fault, a panel in trouble, or a system that needs service, the vendor dispatches a technician and bills a dispatch fee plus labour plus any parts. This is a variable, irregular charge, and it is the main reason invoice totals move month to month.

False-alarm fees. Per-incident fees passed through from the local Authority Having Jurisdiction (AHJ) when a site trips a false alarm. They escalate with repeat incidents and are often charged back to the offending site, which only works if they are pulled out as their own line.

Guard-service post hours. On contracts that include physical guards, the invoice shifts shape entirely: weekly or bi-weekly summaries of post hours, broken into regular, overtime, and holiday hours at a bill rate per category, rather than a flat per-site fee.

Alarm-permit fees. Annual alarm-permit registration or renewal charges, sometimes passed through from the AHJ, posting as a regulatory or licensing expense.

The central point is that each category maps to a distinct GL account, and several sit in genuinely different expense classes. Recurring monitoring is operating expense. An NFPA 72 inspection may be capitalisable. A false-alarm fee is a chargebackable passthrough. A guard-overtime line is variable labour. One undifferentiated security total tells AP none of that, which is exactly why the line items have to come out of the invoice separately rather than as a single posted sum. That same per-line, per-site discipline is what makes any multi-site service invoice workable; it is the structure that lets you turn Iron Mountain records invoices into per-site Excel rows on the records-management side.

Separating Flat Recurring Monitoring From Variable Exceptions

The single most useful thing you can do with a multi-site security invoice is split it along one line: what is fixed, and what is an exception. The largest and most predictable charge is flat per-site recurring monitoring. It is contracted, it repeats, and you can reconcile it against the rate card. Everything that makes a given month's total jump comes from the other side: service-call dispatch, after-hours emergency calls, false-alarm fees, one-off repair or equipment charges. Those arrive irregularly, each needs its own GL coding, and some need review or chargeback before they post.

In the spreadsheet, that split should be structural. Either keep recurring charges and exceptions in separate columns, or add a charge-type column that classifies every row as recurring monitoring, dispatch, false alarm, inspection, guard hours, and so on. With that column in place you can do two things a blended total blocks. You can reconcile the recurring base against contracted per-site rates and catch rate creep after a renewal. And you can route the exceptions: send a dispatch charge for approval, queue a false-alarm fee for chargeback, flag an unexpected repair for the facilities manager to investigate. A single security total per site hides both of those signals at once.

This is also where the facilities manager gets a payoff for free. Once exceptions sit in their own columns, tagged by site, the data answers the questions that manager actually asks: which stores generate the most service calls, where the emergency dispatches cluster, which sites are quietly racking up false alarms. None of that needs a separate report; the AP coding work and the operational read are the same data viewed two ways.

That recurring-base-plus-exceptions shape runs through the whole family of multi-site service contracts, where a predictable per-site fee sits underneath an unpredictable layer of call-outs, so the approach transfers directly. The same method used to extract multi-site pest-control invoices to Excel handles the split the same way, with a different vocabulary of charges on top.

Mapping Each Line to a Site, Cost Centre, and Region

Every line on the invoice has to carry a site identifier, or none of the coding that follows is possible. A 200-site invoice without per-line site tags is an undifferentiated lump: you know the portfolio total and nothing else. With a store number, property code, or branch ID on each line, the same data allocates to a cost centre and rolls up by region, which is what AP and the controller both need.

The friction is that the vendor labels each line with its own account or site number, and that almost never matches your internal store numbering. ADT's account for your Store 412 might be a seven-digit ID that means nothing to your GL. The bridge is a crosswalk: a lookup table mapping each vendor site identifier to your internal store, property, or branch code, and from there to cost centre and region. You maintain that table once, then each month extract the vendor's site identifier onto every row and join to the crosswalk to land the internal codes. The vendor can renumber or re-bill accounts and you only touch the crosswalk, not the extraction.

For that join to work, the site identifier has to repeat on every single row. This is the part people get wrong: on the printed invoice the site number often appears once, as a section header above a block of charges. If the tag is not physically present on each line, the rows are not independently sortable or postable, and the crosswalk join silently drops the unlabelled lines. One row per line item, site number repeated on each, is the rule.

For REIT and property-management readers, clean tagging matters even more: per-property allocation feeds tenant cost recovery and common-area-maintenance reconciliation, so a mis-tagged line is not just an AP nuisance but a billing error that flows through to a tenant statement. The same discipline pays off in plain per-site cost allocation too, letting you compare the recurring monitoring base across the portfolio like for like.

Repeating a site identifier across hundreds of rows and deriving cost-centre codes from it is the kind of structured-output instruction the extraction can be told to follow, adding a cost-centre or region column from the site identifier as the data comes out rather than bolting it on afterward in a sea of spreadsheet formulas. That is the same multi-location allocation pattern used to extract Cintas uniform invoices for multi-location AP, applied to the security charge set.

False-Alarm Fees and the Per-Site Chargeback Workflow

False-alarm fees originate with the local Authority Having Jurisdiction, not the security vendor. When a site trips an alarm that turns out to be false and police or fire respond, the AHJ bills a per-incident fee, and the vendor passes it through on your invoice. These fees escalate as a site accumulates repeat false alarms within a permit year, which is what makes them worth tracking at the site level rather than absorbing into a portfolio total.

The escalation is steep, and it is concrete. Under the City of Albuquerque's false-alarm fee schedule, there is no fee for the first three false alarms in a permit year, a $150 service fee for each false alarm after the third, and a $500 excessive-false-alarm fee per incident once a site exceeds ten false alarms in a permit year. A single store with an oversensitive motion sensor or a staff training problem can run from nothing to hundreds of dollars per incident in a few months. Schedules vary widely between jurisdictions, so the figure on any given line depends entirely on where the site sits.

That variability is the reason the fee has to be extracted as its own line, tagged to the site, and ideally carrying the incident reference where the vendor provides one. With the fee isolated per site, the per-incident amounts roll up into a per-site false-alarm tally across the portfolio. That tally is the chargeback workflow: AP or facilities can total fees by site, surface the repeat-offender locations, and issue an internal chargeback to the store or property that generated the cost. A buried passthrough line becomes an accountable, recoverable number that the offending site sees on its own cost report, which tends to fix the underlying behaviour faster than any memo.

To be unambiguous, because the word collides with a different meaning: this is the municipal false-alarm fee charged back internally to the site that caused it, an internal cost reallocation, not the payment-dispute sense of a chargeback against a card transaction.

Isolating these lines is a classification step the extraction handles directly: instruct it to flag false-alarm fee lines as their own category and carry the site tag onto each, so the per-site tally is already a column when the spreadsheet lands. The extraction classifies and tags what the invoice line states; it does not need to know any city's ordinance to bucket every false-alarm fee against the right site.

Segregating NFPA 72 Fire-System Inspection Charges

Fire-system inspection is a different animal from monitoring, and it has to be coded differently. These are periodic inspection-and-testing charges, billed annually or semi-annually per site under the inspection cycle set by NFPA 72, the National Fire Alarm and Signaling Code. On a combined invoice they usually appear as their own line, distinct from the monthly fire-alarm monitoring fee; just as often they arrive as a separate invoice entirely, on the inspection vendor's own schedule rather than the monthly billing run.

The reason to pull them out is accounting treatment, not tidiness. Because an inspection charge is periodic and tied to a cycle rather than a monthly service, it is frequently capitalised as deferred maintenance or amortised across the period it covers, rather than expensed in the single month it happens to land. Lump it in with recurring monitoring and you have both overstated that month's monitoring expense and lost a charge that the controller wanted handled under a different policy. Getting fire-alarm inspection invoice line items to Excel as their own coded rows is what keeps that distinction intact.

In practice that means flagging inspection charges as their own charge type during extraction, tagged to the site and to the inspection period, so each can be routed to the right GL treatment and tracked against the per-site inspection schedule. Logged that way, you can also see which sites are due, which have been billed, and whether a semi-annual site quietly slipped to annual.

Sprinkler and fire-extinguisher inspections sometimes ride on the same invoice as the alarm inspection. They follow the same logic: segregate them, tag them to the site and period, and code them to their own line rather than folding them into a security monitoring total.

Extracting Guard-Service Post Hours and Auditing Bill-Rate Variance

If your contract includes physical guards, the guard invoice does not look like the alarm-monitoring invoice at all. Instead of a flat per-site fee, an Allied Universal or Securitas guard contract bills weekly or bi-weekly post-hour summaries: for each post, the regular hours, overtime hours, and holiday hours worked, each at its own bill rate. The same site can carry multiple posts, and the same post can mix rate categories within a single week. That shape needs its own extraction model.

The model is one row per post per week, or per pay period if that is how the contract bills. Each row carries the post ID, each hour category as its own field, the bill rate that applies, the resulting amount, and the site the post belongs to. With the data in that form, guard labour is allocatable per site and per post, and it slots into the same per-site spreadsheet as the alarm charges so the full security spend for a location sits together.

The audit payoff is bill-rate variance. When a guard contract renews and the bill rate goes up, the increase is supposed to apply uniformly across every post. It frequently does not, because rate changes are entered post by post and some get missed. Structuring the data per post and per rate makes the gaps visible: you can sort for posts still billed at the prior rate, spot a single site where the renewal never took, and catch anomalous overtime or holiday loading that signals a coding error or a scheduling problem. That is a check you cannot run on a summarised invoice total; it only exists once the post-level detail is in columns.

This is invoice extraction that enables a variance check, not a full guard-labour-rate audit; the point is to surface the pattern from the data you already have to code. Producing one row per post per week, with the hour categories and bill rate as columns and the post and site identifiers repeated on each row, is a line-item extraction the tool handles directly, and that structure is what makes the variance check mechanical rather than a manual crawl through the summary pages.

Why Vendor Portals and Format Inconsistency Force a PDF Extraction

The vendor portals are useful, and it is worth being precise about what they actually give you. ADT Commercial's SecureStat HQ handles multi-site accounts, with MyADT covering the single-site side, and Securitas Technology runs its own customer portal. Through these you can view and pay invoices and pull recurring per-site billing, often as a CSV. For the flat monitoring base, that consolidated reporting and payment view is genuinely helpful and worth using.

Where it stops is the exception detail. Service-call dispatch lines, per-incident false-alarm fees, and guard-hour breakouts are typically not in the consolidated portal download. The CSV gives you the predictable recurring charges and leaves out exactly the variable lines that need the most coding work, the most review, and the chargeback handling. The portal export answers the easy part of the month and goes quiet on the hard part.

The other reason the portal CSV cannot be the whole answer is that the underlying invoices are not consistent, and the cause is industry consolidation. ADT Commercial passed to GTCR in 2024. Stanley Security became Securitas Technology after the 2022 acquisition. Allied Universal absorbed G4S. Johnson Controls carries the Tyco and SimplexGrinnell heritage in its building-systems billing. Convergint and other integrators each bill their own way. Every one of those changes can shift an invoice layout, a line-item label, or an account-numbering scheme, which is why formats differ across vendors and sometimes drift within a single vendor over time. A parser tuned to last year's ADT layout breaks on this year's.

So the dependable source of truth is the consolidated PDF invoice itself, not the portal CSV. The PDF contains every line, including the exceptions the portal omits, regardless of which format this month's invoice happens to use. And because extraction can be driven by a description of what to pull rather than a template mapped to one vendor's column positions, the same instruction handles an ADT Commercial invoice and a Securitas Technology invoice and returns the same structured output from both, even as their layouts diverge. You describe the charge set once, and the inconsistency between vendors stops being your problem to maintain. The same logic that says to process Shred-it and Stericycle invoices for multi-site AP from the source document applies directly to security billing.

---

The Extraction Workflow and Roll-Up to Portfolio-Wide Security Spend

Everything to this point describes the spreadsheet you want; the workflow is how you produce it every month without it becoming a manual ordeal. You start from the consolidated multi-page PDF covering all your sites and finish with the per-site, fully coded spreadsheet the earlier sections specified, joined to the site crosswalk for cost centre and region. Converting that ADT invoice PDF to a spreadsheet is the concrete instance of the whole method, and the volume is what makes it a tooling problem rather than a copy-paste one: 50 to 500 or more sites, monthly, often across more than one vendor. Pasting a few pages at a time into a general-purpose chat tool does not survive that scale; you need consistent, structured output across every page of every invoice, the same way every month. A workflow built to extract multi-site security invoices to Excel automatically from the consolidated PDF, driven by a saved prompt you reuse each cycle, is what makes the monthly run repeatable instead of a fresh project each time.

Concretely, the product handles this as upload, describe, download. You upload the consolidated PDF, or a batch of them across vendors; the platform takes batches of up to 6,000 files and single PDFs up to 5,000 pages, which comfortably covers a multi-vendor, multi-hundred-site month. You describe in a prompt what to extract and how to structure it: one row per line item, repeat the site or store number on each row, classify the charge type, and format the fields. You save that prompt to your library and apply the same one every month, so the output is identical in shape each cycle. Then you download the result as Excel, CSV, or JSON, ready to post or to feed into NetSuite, Oracle, SAP, Sage Intacct, or QuickBooks.

For review and audit, every output row carries a reference back to its source file and page. At portfolio scale that matters: when a controller questions a $500 excessive-false-alarm fee or a guard-overtime spike, you can trace the exact line to the exact page of the original invoice without paging through the PDF by hand. For regulated readers like bank-branch networks, that source-and-page trail is part of what makes the extracted data defensible in an examination, not just convenient.

The roll-up is the reason all the tagging discipline was worth it. With every line tagged by site, cost centre, and region and classified by charge type, the data aggregates into portfolio-wide security spend: the recurring monitoring base, exception spend broken out by site, false-alarm chargeback totals ready to reallocate, inspection spend tracked against the NFPA 72 cycle, and guard labour by site and post. Because the recurring base is isolated, you can also compare it month on month and catch rate creep after a renewal, where a per-site monitoring fee edged up across the portfolio without anyone approving it. This is where the security invoice stops being a monthly chore and becomes part of automating accounts payable across multiple locations, at the same per-site granularity as the rest of the portfolio.