Pest Control Invoice Reporting Schema: Fields and Categories

A pest control invoice reporting schema is a vendor-agnostic field taxonomy organised into nine purpose-built groups. They are:

1. Invoice header
2. Customer and site
3. Service visit
4. Pest and treatment
5. Labor and service charges
6. Materials and chemicals
7. Tax and fees
8. Source-document traceability
9. Reporting outputs (GL account, cost centre, location code, job or route code, taxable flag)

The point of the schema is not the column list on its own. It is the discipline of capturing every group at the line level, so the resulting spreadsheet can answer the operational questions finance is going to ask of it.

Line-level capture is what makes the rest of the workflow possible. It is how AP teams allocate cost by site when one invoice covers many locations. It is how the spreadsheet complies with the separately-stated taxable-versus-nontaxable rule that several US states impose on pest-control invoicing. And it is how every individual charge — a chemical application, a bait-station replacement, a callback visit, an environmental fee — stays traceable back to the underlying service report and the source PDF it came from. An invoice-level rollup loses all of that.

The searcher's question, in plain terms, is what columns and categories belong in a pest-control invoice spreadsheet or extraction prompt — and the SERP currently does not answer it. The pages ranking on this query are pest-control invoice templates: layouts an operator uses to print their own invoice, with a charges table, totals, and payment terms. Useful for the operator. Not useful for the bookkeeper, controller, or multi-site AP team on the receiving end, who is not trying to produce an invoice. They are trying to make a stack of incoming invoices queryable.

This article delivers the reporting schema that question is actually asking for. The schema is built to apply across mixed vendor formats — Orkin, Terminix, Rentokil, Ehrlich, and local pest-control operators all map into the same nine field groups — so the finance reader adopts one set of columns regardless of which supplier sent the invoice. Each of the next nine sections defines one field group: the specific columns inside it and the finance-side reason each column is captured. The closing two sections cover how the schema becomes an extraction prompt and how to run it against named-vendor batches.

Why a reporting schema differs from an operator invoice template

An operator invoice template and a reporting schema are different artefacts that solve different problems. An operator template defines what a pest-control business prints onto an invoice it sends out: header, charges table, totals, payment terms, sometimes a few operational compliance fields like the technician's signature or the EPA registration numbers of products applied. It is a layout for the producing side of the transaction. A reporting schema defines the columns a finance reader needs in a spreadsheet to answer downstream questions on the receiving side: how much did each location spend last quarter, which line items were taxable, what posted to which GL account, where in which PDF did that figure originate.

The optimisation targets pull in opposite directions. An operator template optimises for what looks right on a printed page. A reporting schema optimises for what is queryable in a spreadsheet. That is why the schema groups its fields by purpose rather than by the order they appear on the invoice. It is why labor and materials are reserved as distinct line types instead of rolled into a single service charge. It is why EPA registration numbers earn their own column rather than living inside a free-text description. And it is why the schema carries columns an invoice form never carries — GL account, cost centre, location code, source file name, page number — because the spreadsheet's job extends past restating the invoice.

The line-level point is the one that does most of the work. Invoice-level totals are not enough. A spreadsheet that holds one row per invoice can tell the reader what each invoice cost in total, and not much else. It cannot answer how much each location spent on chemicals last quarter, because chemicals are not separated from labor. It cannot produce a taxable-revenue subtotal that complies with separately-stated taxable-charge rules, because every line on an invoice may have its own taxable status. It cannot trace a specific charge back to the service report that authorised it, because the linkage runs through line-level service-visit identifiers. Line-level capture — one row per material applied, one row per labor line, one row per fee — is what turns the spreadsheet into a working finance artefact.

The same pattern shows up in adjacent facility-services categories. Multi-site finance teams who run janitorial contracts across portfolios of locations face an almost identical problem: many vendor formats, one schema needed across all of them, the same per-site allocation and audit-evidence requirements. The multi-site janitorial invoice extraction schema covers that adjacent case in detail. The shape of the answer there is the same — a purpose-grouped column list captured at the line level — even though the specific compliance fields differ.

What follows is a section per field group. Each section names the specific columns the group contains and explains the finance-side reason each column is captured. Some groups are short. Some are longer because the pest-control-specific detail does real work in them.

Invoice header fields

The first group is the standard set of header columns every supplier invoice carries, with one or two pest-control-specific nuances. The specific columns: vendor legal name, vendor trading name where it differs from the legal name, vendor tax ID or EIN, vendor address, invoice number, invoice date, billing period start, billing period end, due date, payment terms, currency, and the invoice-level total amount.

Most of these earn their place for reasons that hold for any AP workflow. Vendor legal name plus trading name lets AP reconcile invoices from "Orkin LLC" and "Orkin Pest Services" against a single vendor master record rather than treating them as two suppliers. Invoice number and invoice date drive duplicate-payment prevention and aging. Due date and payment terms feed cash-flow planning. Currency matters as soon as the customer operates across more than one region.

The billing-period columns are where pest-control invoicing differs from ad-hoc supplier work and where the schema needs to be explicit. Pest-control vendors overwhelmingly bill on a recurring cadence — monthly for most commercial accounts, quarterly for some — covering scheduled service visits delivered within a defined window. An invoice dated 2 April that covers service performed across March needs both the period-start (1 March) and period-end (31 March) captured as their own columns, distinct from the invoice date. Without that separation the spreadsheet cannot join the invoice to the right month's GL period, and the recurring-service reconciliation against the master service agreement breaks.

The invoice-level total amount is captured as a header column for completeness, but it functions in the schema as a check figure. Once labor lines, materials lines, tax, and fees are captured at the line level in the sections that follow, the sum of those lines should reconcile to the header total. Where it does not, the spreadsheet surfaces a data-quality flag immediately rather than letting a posted invoice quietly drift away from its underlying detail.

Customer and site identifiers for multi-site allocation

For any operator running pest-control across more than one location — a restaurant group, a property manager, a multi-store retailer, a food-processing or healthcare network — the customer-and-site group is the schema's load-bearing piece. Without these columns the spreadsheet cannot allocate cost by site, and per-location reporting collapses into one undifferentiated vendor-spend figure.

The specific columns: location ID (the customer's own internal site identifier), store or unit number, building or unit identifier within a multi-building site, route ID (used by some vendors to group sites under a service route), site address split into street, city, state and postal code as separate columns where possible, billed-to entity (the legal entity receiving the invoice), and PO or contract reference.

Multi-site identifier columns deserve special attention because the most common failure mode is collapsing them. Pest-control vendors who serve multi-site operators reference each site in different ways. Orkin uses an internal customer site number alongside the site address. Terminix carries a route and a customer ID. Rentokil and Ehrlich typically reference a service location code. A local operator may identify the site only by its street address. The schema's job is to capture every identifier the vendor provides as its own column rather than picking one and discarding the rest. That redundancy is what makes the spreadsheet joinable back to the customer's own location master under whichever identifier the customer's books actually key on.

Billed-to entity is captured separately from site address for a related reason. A corporate AP team can receive a single invoice covering pest-control services delivered to a dozen sites under different operating subsidiaries — particularly common where a parent entity holds the master service agreement and is billed centrally for work performed at locations owned by its subsidiaries. The billed-to entity (the legal AP entity, the one writing the cheque) and the service-delivery entity (the operating entity at the site) need to be queryable independently, because they post differently in the books.

PO or contract reference closes the group. Pest-control work is almost always performed under a master service agreement, and most large customers issue a PO or a contract number per site against that agreement. Capturing this column lets AP match each invoice line to a specific commitment and surfaces invoices that arrive without a valid PO reference — a routine red flag that the work was either unauthorised, billed under the wrong site, or attached to a contract that has expired.

Service visit details that link the invoice to the field record

This is where the schema connects each invoiced charge to what actually happened on site. The finance reader approving a pest-control invoice is rarely on site to verify the work, so the service-visit columns are their primary control against being billed for services that did not happen as described or that should have been billed at a different rate.

The specific columns: service date (the date the visit was actually performed, which routinely differs from the invoice date), visit type (scheduled, extra, emergency, inspection, re-treatment, callback), service-report or work-order ID (the vendor's reference for the field record produced during the visit), technician identifier (name or employee number), technician licence number (the state pest-applicator licence, mandatory in most US states for commercial pest-control work), and route ID where the vendor organises service by route.

Visit type earns its own column because the chargeability rules differ across types. Scheduled visits are billed under the recurring contract rate. Extra and emergency visits usually carry a different rate, and most contracts specify which scenarios make an extra visit chargeable versus included. Callbacks — visits the customer requested because a previous treatment did not resolve the issue — are typically meant to be free under the contract's service guarantee, but vendors sometimes bill them anyway. Without a visit-type column captured discretely on every line, every charge looks the same to the finance reader and rate validation becomes impossible to automate.

The service-report or work-order ID column is the join key between the invoice spreadsheet and the operational record of what happened during the visit. Every invoiced line should be traceable back to a single field record that documents pest activity observed, areas treated, devices serviced, chemicals applied, and any recommendations made to the customer. The service-report ID is what makes that traceability possible across systems — even when the invoices live in AP and the service reports live in the vendor's customer portal or a third-party CMMS. The same field-ticket discipline that drives field ticket and service report invoice approval in other field-service categories applies directly: an approved invoice line is one that ties back to an approved field record.

Technician identifier and licence number columns sit alongside as the audit evidence. Pest-applicator licensing is regulated at the state level, and customers operating in regulated environments — food processing, healthcare, schools, federal facilities — often need to prove that every on-site pest-control treatment was performed by a licenced applicator. Capturing the licence number on every line, rather than once per visit or not at all, is what lets that proof land in a single spreadsheet filter when an auditor asks for it.

Route ID closes the group for customers whose vendors organise service geographically. A route number on the invoice is often the most reliable join key into a vendor's own scheduling and service-history data, which matters when investigating a billing dispute or reconstructing a year's worth of service activity for a site.

Pest and treatment classification fields

The compliance-and-operations group. These columns are not financial figures, but they earn their place in a finance schema because they are what a finance reader uses to validate that an invoiced service line matches the work documented in the underlying service report.

The specific columns: pest category (rodent, cockroach, ant, stored-product insect, termite, bed bug, occasional invader, wildlife, mosquito, fly), treatment type (chemical application, bait placement, exclusion work, trapping, fumigation, heat treatment, monitoring-only), treatment area or zone (interior structural, perimeter, kitchen, dock, exterior bait stations, roof, attic — the exact zone taxonomy varies by vendor), and the IPM evidence columns: devices serviced (the count of bait stations, traps, or monitors checked or replaced during the visit), findings (pest activity observed or conditions noted), and recommendations to the customer (exclusion work needed, sanitation issues flagged).

The finance-side justification is reconciliation, not pest-control expertise. If an invoice line reads "rodent service, perimeter, $185" but the corresponding service report's findings column shows no rodent activity and zero devices serviced, that mismatch is a discrepancy a finance reviewer wants visible in the spreadsheet rather than buried in a PDF nobody opens. The pest, treatment, and area columns let the spreadsheet pivot or filter to surface those mismatches systematically across a month of invoices, instead of relying on someone manually opening service reports one at a time.

The IPM (integrated pest management) framing matters for any customer in a regulated environment. Food processing, healthcare, schools, and federal buildings all require IPM-based documentation — proof that pest control is being managed through monitoring, exclusion, sanitation guidance, and targeted intervention rather than blanket chemical application. The devices-serviced count, the findings notes, and the recommendations column are the schema's nod to that requirement. Customers in those industries cannot drop these columns and still satisfy an auditor or insurer.

One practical note on treatment area: it should be captured at the line level when the vendor breaks a visit into multiple line items by zone. Larger commercial accounts often see exterior bait-station service, interior structural treatment, and any specialty work (drain treatment, attic application, specific equipment area) billed as separate lines on the same invoice. Collapsing those into a single "service" line destroys the per-zone cost and the per-zone compliance evidence in one move.

Labor and service charges, separated from materials

Labor and materials need to live as distinct line types in the schema. The reason is bookkeeping, not pedantry: rolling them into a single service line makes COGS reporting impossible to reconstruct from the spreadsheet and prevents the kind of service-revenue analysis that the schema is built to support.

The specific columns in the labor group: service-line categorisation (recurring scheduled service, callback or extra visit, emergency response, one-off inspection, exclusion or remediation labor), labor hours where the vendor bills time-and-materials rather than a flat visit rate, labor rate, labor line amount, and a recurring-versus-one-off flag.

The separation from materials is the schema's central rule on this group. Many pest-control vendors already invoice with labor and materials on separate lines, and the schema's job there is to preserve the separation rather than collapse it during extraction. Where a vendor consolidates — a single line reading "monthly pest service, $245" with materials bundled in — the schema still reserves the labor and materials columns so the line can be split during extraction (where the vendor's detail page or service report supports it) or flagged for manual reclassification. A schema that quietly merges labor and materials inherits all the downstream problems of an invoice that does the same.

The recurring-versus-one-off flag is a small column that does disproportionate work. Recurring scheduled-service revenue behaves differently from extra-visit revenue for budgeting, for vendor-spend analysis, and for surfacing trends that matter operationally. A finance reader who can filter the spreadsheet to one-off lines instantly sees whether extras are climbing as a share of total pest-control spend — a leading indicator that the underlying pest-control programme is not working, or that sites are bypassing the master contract and calling in ad-hoc work.

Service-line categorisation does similar work at a slightly different level. Pest-control invoices commonly mix scheduled service, callbacks, and remediation labor in a single document. The category column lets the spreadsheet pivot or filter on category to produce, for instance, a quarter's split between scheduled and reactive spend across a portfolio of sites. That split is a useful operational metric in its own right, and it is unrecoverable from a spreadsheet that treats all service lines as the same type.

The approval discipline around service-based invoicing borrows from the broader pattern used for service entry sheet controls for service-based invoices: the labor line is supposed to be backed by an approved record of service delivery, captured at the line level rather than at the invoice header. Where the customer's process supports it, an approver field or an approved-by-reference can be carried alongside the labor columns to close the control loop.

Materials, chemicals, and device units

Materials are where the pest-control schema diverges most sharply from a generic supplier-invoice schema, and where line-item granularity matters most. Every chemical product applied during a visit, and every device serviced or replaced, has its own row in the spreadsheet.

The specific columns: product or chemical name, EPA registration number, active ingredient where the vendor lists it separately, quantity applied, unit of measure (ounces, gallons, grams, bait stations, traps, monitoring devices), concentration where listed, and the line amount charged for the material.

The EPA registration number column is non-negotiable. The EPA assigns a unique registration number to every pesticide product legally sold in the US, and regulated customers — food service, healthcare, schools, federal buildings, and any operator subject to third-party audits like AIB, BRC, or SQF — must be able to produce a record of every pesticide product used on premises by EPA reg number. A schema that captures the product name only, and skips the EPA reg, leaves the customer unable to answer that request without going back to the original service reports and reading them line by line. Make the EPA reg a required column.

Device units sit alongside chemicals in the materials group, but they behave differently and need to be captured as their own product type rather than dumped into a generic "supplies" bucket. Bait stations, snap traps, glue boards, and rodent monitoring devices are billed per unit serviced or replaced. They carry a unit count and a line amount, which makes them materials in the schema's sense, but the operational reporting customers want around them — how many bait stations were serviced at site X this quarter, how many traps were replaced versus inspected — depends on the device type being identifiable as a device rather than buried under the same column header as the chemicals.

Line-item granularity is what makes the materials group work. A single service visit might involve three different chemical products applied to two zones, plus twelve bait stations replaced and four rodent monitors checked. The schema captures that visit as roughly four to seven distinct material rows: each chemical product as its own row (with its own EPA reg, quantity, and concentration), and the device servicing as a separate row or rows. Rolling all of that into a single material line destroys the compliance evidence at the EPA-reg level and destroys the per-product spend analysis that lets a customer notice, for example, that one product is being over-applied across their portfolio or that bait-station replacement costs have crept up under a particular technician.

The materials lines reconcile back to the invoice-level total alongside labor and tax, the same header-versus-line check called out in the invoice header section. A materials subtotal that fails to reconcile is exactly the kind of data-quality signal the schema is designed to surface.

Tax and fees, and the separately stated taxable rule

Tax is the field group where pest-control invoicing carries a compliance requirement that most other supplier categories do not, and where the schema's line-level discipline pays for itself.

The specific columns: taxable status flag on each line (taxable or nontaxable), tax rate, tax amount, jurisdictional tax breakdown columns where multiple jurisdictions apply (state, county or local, special district), and separate columns for the non-tax additions that commonly appear on pest-control invoices: fuel surcharge, environmental or regulatory fee, trip charge, after-hours surcharge.

The reason every line carries its own taxable flag, rather than a single invoice-level tax figure, is the separately-stated taxable rule that several US states impose on pest-control invoicing. The clearest articulation comes from Texas. According to Texas Comptroller Publication 94-114 on pest control services, in Texas, when a pest control business performs both taxable and nontaxable services, the invoice must separately state the charges for the taxable and nontaxable services and collect tax only on the taxable service charges. At the schema level that translates into a hard requirement: every line needs its own taxable / nontaxable flag, every line carries its own tax amount where applicable, and an invoice-level tax rollup is not enough to prove compliance with the rule.

Texas is the cited example, but the broader point is that several other US states impose similar separately-stated requirements on pest-control or related taxable services, with the exact rules and the exact definition of taxable services varying by state. Any customer operating across more than one US state cannot rely on the rules of a single jurisdiction. The schema's per-line taxable flag is what makes multi-state reporting possible without restructuring the spreadsheet every time a new jurisdiction comes into scope.

The fee columns earn their separation from tax for spend-analysis reasons. Fuel surcharges and environmental or regulatory fees commonly appear on pest-control invoices as non-tax additions, and trip charges and after-hours surcharges show up on extras and emergency calls. Capturing each as its own column (or, at minimum, capturing a generic "fee" column alongside a fee-type subcolumn) is what lets a finance reader notice that fuel surcharges have crept up to ten percent of one vendor's invoice value across the year, or that trip charges are concentrating at a small set of sites. A generic "other" lump on every invoice hides all of that.

The taxable flag captured here feeds directly into the reporting outputs covered in the next section but one. Per-line tax capture is not data collection for its own sake; it is what makes the taxable-revenue subtotal usable downstream.

Source-document traceability for audit evidence

The traceability group is short — three columns — and quietly does more work than any of the other groups when something goes wrong and the spreadsheet has to defend itself.

The specific columns: source file name (the original PDF filename as received from the vendor), page number within that source file (the exact page where the line item appeared), and line position on the page (the line number, or a row index into a multi-line table on the page).

The use case is the round trip. An auditor, a controller, a franchise owner, or a multi-site operator asks where a particular figure on a posted invoice came from. The finance reader filters the spreadsheet to one row, reads the source file name and page number, opens the PDF to that page, and finds the original line item exactly where the spreadsheet says it is. Without these columns the round trip becomes a manual search across many PDFs in a shared drive, and the spreadsheet stops being audit evidence the moment the underlying documents stop being easy to locate.

These columns belong in the schema rather than being treated as optional extraction metadata. For pest-control specifically, the volume problem is real. A single PDF received from a vendor can contain a month of consolidated invoices with service-report appendices attached, running into dozens of pages and hundreds of line items. A spreadsheet output from that PDF that does not record which line came from which page is impossible to defend at audit. The reader who is asked to support a $2,400 chemical line in a $48,000 monthly invoice should be able to find that line in seconds, not in twenty minutes of scrolling.

Traceability also stays robust across mixed-vendor batches. When a single extraction run produces a spreadsheet covering rows from Orkin invoices, Terminix invoices, Rentokil invoices, and a few local-operator PDFs, the source file name column tells the reader which vendor produced each row without depending on a vendor name column whose values may not match cleanly across formats. That redundancy is cheap to capture and useful every time a vendor-name field is missing, abbreviated, or extracted inconsistently.

Reporting outputs: GL, cost centre, location, taxable flag

The ninth group is the one that lets the spreadsheet answer the operational questions everything else is set up to support — per-location cost, per-account rollup, taxable-revenue subtotal by jurisdiction.

The specific columns: GL account (the chart-of-accounts code the line will post to), cost centre or department code, location code (the customer's own location identifier, distinct from the vendor's site ID captured earlier), job or route code where the work is tracked under a project or internal route, taxable-revenue flag derived from the per-line tax flag in the previous section but one, and any operating-unit or subsidiary code the AP team uses for multi-entity bookkeeping.

These belong in the schema rather than being treated as columns to add manually after extraction. A schema that requires the finance reader to append GL, cost centre, and location codes after the spreadsheet is produced is a schema that gets used once and then quietly abandoned in favour of whichever ad-hoc layout next month's bookkeeper invents. Treating these columns as part of the schema itself — populated during extraction where the source document supports it, derived from mapping rules where it does not — is what keeps the workflow repeatable.

Vendor site ID and customer location code need to coexist as separate columns even though they describe the same physical site. Vendor site IDs are how the supplier identifies the site on their invoice (covered in the customer-and-site group earlier). Customer location codes are how the customer's own books and operational systems identify the same site. The reconciliation between the two typically runs through a mapping file the customer maintains and that gets reapplied to each month's spreadsheet. The schema's job is to carry both columns so the join can happen at all; collapsing them into one column on the assumption that the vendor's ID and the customer's ID are the same is exactly the assumption that breaks during onboarding of a new vendor or after a site code change.

The GL account column needs to be captured at the line level rather than at the invoice level. Most routine pest-control charges code to a single facility-maintenance or pest-control expense account, but materials sometimes code to a separate supplies account depending on the customer's chart of accounts, and remediation or capital-related work — rodent exclusion involving structural repair, attic or crawlspace remediation, sealing and proofing work — may need to capitalise rather than expense. A line-level GL column accommodates the split without forcing every line of an invoice into the same account on the way to the books.

The taxable-revenue flag in this group is a derived column rather than a captured one: it rolls up the per-line tax flag from the tax-and-fees group into a form that pivots cleanly. Several state and local tax filings require a taxable-revenue subtotal by jurisdiction, and the flag is what makes that subtotal a single pivot away rather than a recompute.

Together, these reporting-output columns are why the upstream groups insist on line-level capture. Per-line GL, per-line cost centre, per-line location code, and per-line taxable flag are how the spreadsheet answers per-location, per-account, and per-jurisdiction questions later. None of that works if the upstream lines have been rolled up.

---

Turning the schema into an extraction prompt

The schema is a column list. The practical follow-up is how to get a stack of varied pest-control PDFs to populate that column list in one spreadsheet without rebuilding the workflow per vendor.

A prompt-based extraction tool — one that takes a natural-language instruction plus a batch of files — handles this directly. The column list itself becomes the prompt. The user names the columns the way the schema names them (location ID, store number, route ID, billed-to entity, service date, visit type, service-report ID, technician licence number, pest category, treatment area, EPA registration number, taxable flag, source file name, page number, GL account, and the rest), specifies line-item output rather than invoice-level rollup, and calls out the pest-control-specific requirements explicitly: every chemical product as its own row with its EPA reg, every labor line separated from materials, every line tagged with its own taxable status.

Line-item output is the single most important instruction in the prompt. It is also the easiest to get wrong by omission, because most extraction defaults to one row per invoice unless told otherwise. The schema breaks the moment the output collapses to invoice level — per-site allocation fails because one invoice can cover many sites, taxability compliance fails because the per-line flag has nowhere to live, audit traceability fails because line-position references stop being meaningful. The prompt has to insist on one row per material applied, one row per labor line, and one row per fee.

Source-file and page traceability comes next on the list of things the prompt has to ask for explicitly. The traceability group covered earlier — source file name, page number, line position — needs to be populated automatically as part of each extracted row, not added later. A spreadsheet that arrives without those columns cannot serve as audit evidence regardless of how accurate the other columns are.

Saved prompts are how the schema becomes operational rather than a one-off effort. Pest-control invoicing is overwhelmingly monthly or quarterly, which means the same schema gets reapplied across the same recurring batch shape every cycle. A saved prompt encodes the column list once — including the line-item instruction, the EPA-reg requirement, the per-line taxable flag, the traceability columns — and gets pointed at next month's batch unchanged.

The other piece is batch handling for mixed vendor formats. In a real AP setting, a month of pest-control work arrives as a heterogeneous stack: Orkin invoices in one layout, Terminix in another, Rentokil and Ehrlich each in their own, a few local-operator PDFs with no layout consistency at all, and the occasional emailed work order. The extraction tool has to process all of them in one job and produce one consistent spreadsheet matching the schema — which is the point at which a prompt-driven approach diverges from per-vendor template parsers that would need a separate template configured for each layout.

Invoice Data Extraction operates this way. The interface is a single prompt field and a file upload area, with no templates to configure per vendor — AI invoice data extraction where the prompt itself is the configuration. The user types the schema's column list into the prompt (or applies a saved version from the prompt library), uploads the month's mixed vendor PDFs, and downloads an Excel, CSV, or JSON file. Line-item output produces one row per chemical product, one row per labor line, one row per fee, with the invoice header fields repeated on each row. Source file name and page number are populated on every row. The prompt library holds the schema for reuse against subsequent monthly batches, and batch processing accepts up to 6,000 mixed-format files per job.

Running this schema on named-vendor batches

The natural next step for a reader who has adopted the schema is running it against the specific vendors they actually receive invoices from each month. That is a different artefact — a runbook for the named-vendor, multi-site execution workflow rather than a schema reference.

The companion piece that covers that workflow in detail is extract multi-site pest control invoices to Excel. It walks through the named-vendor case — Orkin, Terminix, Rentokil, Ehrlich, and the local-operator stack that typically rounds out a portfolio — and covers the per-location GL-coding execution against a real monthly batch.

The vendor-agnostic point is worth ending on. The schema is designed so a finance reader can produce one spreadsheet across a mixed batch of vendor PDFs without restructuring the columns per vendor. Orkin's invoice layout, Terminix's invoice layout, Rentokil's invoice layout, and the average local operator's invoice layout all carry the same nine field groups, expressed differently. The extraction approach is what reconciles the layout differences into a uniform output; the schema is what the uniform output looks like.