How to build a checkable facilities rate card

Executive Summary

Facilities invoices are hard to check because the pricing lives in a contract, not a system. A management agreement might set a base fee, a per-visit rate for extra services, an escalation clause tied to an index, and a different price schedule for each site. None of that is usable at the point an invoice arrives unless someone has already translated it into a flat table AP can look up in seconds.

The fix is a facilities rate card: one row per vendor, per site, per service line, with the current unit price and the date range it is valid for. Building it means pulling every active facilities contract, extracting the pricing terms exactly as written, structuring them into that row format, and putting an owner and a review date on the result so it does not go stale the way the source contracts already have.

What changes is not the contract. It is whether AP has something to check the invoice against at the moment it lands, instead of finding the mismatch in a recovery audit eighteen months later.

1. What belongs on a facilities rate card?

A facilities rate card needs six fields per row: vendor name, site or location, service line, unit of measure, unit price, and the effective date range for that price. Anything less and AP cannot resolve which price applies to a given invoice line. Anything more, like internal cost codes or GL mappings, belongs in a separate table so the card itself stays something a non-finance reviewer can read at a glance.

Facilities contracts mix pricing models inside a single agreement: a flat monthly fee for routine janitorial, a per-hour rate for extra labor, a per-call rate for HVAC service outside scheduled maintenance, and sometimes a materials markup. Each of these is a distinct row on the card, not a note in a comments field.

The unit of measure matters as much as the price. "$45" means nothing without knowing if it is per visit, per hour, per square foot, or per unit serviced. AP staff checking an invoice against a card that omits the unit end up guessing, which reintroduces the exact ambiguity the card exists to remove.

Site-level rows matter more in facilities than almost any other category, because a single vendor often serves multiple locations at different prices, set by local labor cost or square footage. A card that averages these into one company-wide rate will pass invoices that are individually wrong even though the portfolio total looks fine.

2. How do you extract pricing terms from a facilities contract?

Pull every active facilities contract and read only the pricing exhibit, the fee schedule, and any amendment letters, ignoring the boilerplate. Extract each rate exactly as written, including the unit, the site it applies to, and any escalation clause, into a working spreadsheet before you touch formatting. Extraction and formatting are separate steps; combining them is where transcription errors get introduced.

Most facilities agreements bury pricing in an exhibit or schedule attached at the back, not in the body of the contract. Amendments and side letters often change a single site's rate without reissuing the whole agreement, so the current price is sometimes not in the original document at all.

A reliable extraction pass reads, in order: the base fee schedule, any exhibit listing per-site variations, the escalation or index clause, and every amendment in date order. Record the source page or exhibit number next to each extracted rate. When a dispute comes up later, being able to point to the exact clause is what makes the rate card defensible rather than just convenient.

Do not resolve conflicts during extraction. If two documents state different prices for the same site and service, record both with their dates and flag the conflict for the next step. Silently picking one during extraction hides a contract governance problem instead of surfacing it.

3. How do you handle escalation clauses and price changes?

An escalation clause is a formula, not a static number, so the rate card needs a way to show both the base rate and the rule that changes it. Record the trigger, a renewal date, an index, a fixed annual percentage, the last date the rate was actually updated, and the next date it is due to change. A card that shows only today's number will silently go stale at the next escalation date.

Treat the escalation clause itself as data, not commentary. A card entry that only carries today's number gives AP nothing to check the escalation against once the trigger date passes, and the invoice arriving that month is exactly the one where the wrong rate will slip through.

A. A. Fixed-date escalators

Some facilities contracts step the rate on a set calendar date, often the contract anniversary. Record that date on the card as the next review trigger and set a reminder well before it, since the invoice due on that date is the first place the new rate needs to be live.

B. B. Index-linked escalators

Where a contract ties pricing to an external index, the rate card cannot show a single number indefinitely. Record the formula and the index name, and treat each recalculation as a card update event with its own effective date, not a one-time setup task.

C. C. Discretionary or negotiated increases

Some agreements allow a vendor to propose an increase subject to notice or approval. These need a status field, proposed, approved, or rejected, because an invoice reflecting a proposed rate that was never approved is exactly the kind of drift a card is built to catch.

4. Who should own the facilities rate card once it is built?

One named owner, not a shared drive, should hold responsibility for the facilities rate card: usually the AP lead or a facilities category manager who also receives contract amendments as they happen. Without a single owner, the card and the underlying contracts drift apart within a few cycles, because nobody is accountable for pushing amendment terms into the table the day they are signed.

The card's value comes entirely from staying current. A rate card built once and never touched again is a snapshot of last year's contract, and it will start passing invoices it should be rejecting the moment a single price changes.

Ownership works best when it is tied to the contract renewal and amendment process, not to a calendar review alone. Whoever signs off on a facilities contract change should have updating the card as an explicit step in that approval, not a downstream cleanup task assigned to someone else weeks later.

A review date belongs on the card itself, alongside the pricing data, so anyone using it can see how current it is. A card with no visible review date reads as authoritative even when it is a year stale, which is worse than having no card at all.

5. How does AP actually use the card to check an invoice?

AP matches each invoice line to a card row by vendor, site and service line, then compares the invoiced unit price against the card's current rate for that date. A match within tolerance clears; a mismatch gets held for review rather than paid on faith. This is a manual lookup process the card is designed to support, not a system the card depends on.

The workflow is deliberately simple: for each invoice line, find the row with the matching vendor, site, and service description, confirm the invoice date falls inside that row's effective date range, and compare the price. This is the same logic a match check performs against a purchase order, applied instead to a contract pricing table that most ERPs have nowhere to store.

A facilities rate card does not replace whatever matching the ERP already does. It adds a check for the piece the three-way match gap in most ERPs cannot see: contract pricing terms that live in a PDF exhibit rather than a purchase order line. Vendor master hygiene matters here too, since a duplicate vendor record can split one supplier's invoices across two names and make the card lookup fail silently.

6. What should you check before trusting the card is complete?

Before putting a facilities rate card into daily use, confirm four things: every active contract is represented, every site has its own row where pricing differs, every escalation clause has a next-trigger date recorded, and the card has a named owner and a visible last-updated date. Skipping this checklist is how a card looks complete on the day it launches and is already wrong within a quarter.

Once the checklist passes, run the card against a sample of recent facilities invoices before relying on it for live processing. Pick invoices spanning several vendors and at least one site with a known price variation, and manually work each one through the lookup process AP will use going forward. Price file governance practices used for other spend categories apply here too: treat the card upload or edit as a controlled event, not an ad hoc change.

Any mismatch found in this test pass is useful information. It either means the card has an error worth fixing before launch, or it means the invoice itself was wrong and the card just did its job a quarter before a formal audit would have caught it.

1. Full contract coverage: List every active facilities vendor and confirm each has a corresponding set of rows. A vendor missing from the card is a vendor AP cannot check at all.
2. Site-level granularity: Confirm multi-site vendors have a row per site where the contract sets different prices, not one blended rate for the whole relationship.
3. Escalation dates recorded: Every row governed by an escalation clause needs its next trigger date visible, so a stale card is flagged before it silently passes an outdated price.
4. Named owner and review date: The card should show who maintains it and when it was last checked against the underlying contracts, not just the pricing data itself.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

How often should a facilities rate card be updated?

Update it every time an underlying contract changes: a renewal, an amendment, or an escalation clause triggering. Beyond event-based updates, set a fixed review date, quarterly is a reasonable cadence for most facilities portfolios, to catch anything that slipped through without a formal amendment.

Does a facilities rate card need special software to maintain?

No. A well-structured spreadsheet with the six core fields, vendor, site, service line, unit, price, and effective dates, is sufficient for most facilities portfolios. The discipline is in the structure and the update process, not the tool.

What is the difference between a rate card and the contract itself?

The contract is the legal source of truth and includes terms a rate card does not need: termination clauses, liability language, service level definitions. The rate card extracts only the pricing terms and restates them in a flat, lookup-friendly format AP can use without reading the full agreement.

Should the rate card include tax or fuel surcharges on facilities invoices?

Keep those in separate fields if they apply, rather than folding them into the unit price. Facilities invoices sometimes add a fuel or materials surcharge on service calls, and blending it into the base rate makes both numbers impossible to check independently.

What happens when a vendor invoices a price that is not on the card at all?

Treat it as an exception, not a default approval. A price with no matching row usually means either a new service line was added without updating the card, or the vendor is billing for something outside the contract. Both need review before payment, not after.

Can one rate card cover multiple facilities vendors, or does each need its own?

One consolidated card covering all facilities vendors works well, as long as vendor name is a required field on every row. A single table is easier for AP to search than a folder of separate vendor files, provided the structure stays consistent across vendors.

How does a facilities rate card relate to a three-way match in the ERP?

A three-way match checks the invoice against the purchase order and the receipt. It does not test whether the unit price itself is the one the contract sets, especially where facilities services are billed against a blanket PO with no line-level pricing. The rate card fills that specific gap.

Who should build the initial facilities rate card, AP or procurement?

Either can lead, but the build needs input from whoever holds the signed contracts, often procurement or facilities management, and whoever will use the card daily, AP. Building it in isolation from either side produces a card that is either inaccurate or unusable.

What is the biggest risk in maintaining a facilities rate card long-term?

The card silently going stale after a contract amendment that nobody pushed into the table. This is why ownership and a visible last-updated date matter as much as the initial extraction accuracy.