Rate Card Enforcement: Approved Timesheets, Wrong Invoices

Executive Summary

The control gap is structural, not a training problem. Timesheet approval workflows verify attendance: did this person work these hours on this job. They were never built to verify pricing, because pricing lives in a separate document, the master service agreement or statement of work, that the approving manager rarely has open when they click approve.

The invoice that follows an approved timesheet inherits whatever rate the staffing vendor's billing system applied, which may be a stale rate card, a default bill rate, or a rate for the wrong labor category. None of that gets caught downstream either, because AP's three-way match tests the invoice against the purchase order and the goods receipt, not against the contract's rate schedule.

What changes it is treating the rate card as a control object with its own check, separate from hours approval. That means matching invoiced rate to contracted rate by labor category, tier, and effective date, on a cadence independent of who signed the timesheet.

1. Why do approved timesheets still produce invoices at the wrong rate?

Timesheet approval and rate enforcement check different things. Approval confirms a person worked the hours shown; it says nothing about which bill rate applies to that person's role, tier, or shift. The invoice is generated from the vendor's billing system against its own rate table, not against the buyer's contract, so an approved timesheet can still produce an invoice priced off a stale, default, or mismatched rate.

A timesheet approval workflow answers one question: did the named worker perform the hours logged, on the job or cost center shown. That question sits entirely on the labor side of the transaction. The manager approving it is checking a calendar against a memory, not a contract against a price.

The rate that ends up on the invoice is generated separately, inside the staffing vendor's own billing system, against whatever rate table that system has loaded for the worker's labor category. If the vendor's rate table has not been updated to match a contract amendment, or if the worker was coded to the wrong tier, the invoice will be internally consistent and still wrong.

Because the hours match and the invoice format looks normal, nothing about the document itself signals a problem. The rate has to be checked against the contract directly, line by line, by category and effective date, which is a different control than hours approval and is rarely built into the same workflow.

2. What does a rate card actually specify?

A rate card is the contract schedule that ties a bill rate to a specific labor category, skill tier, shift differential, and effective date range. It is the reference the invoice should be checked against. When a contract is amended, the rate card changes; when the vendor's internal billing system is not updated to match, the two versions diverge and every subsequent invoice inherits the older, wrong number.

A rate card is not a single number. It is a table: labor category on one axis, tier or certification level on another, sometimes a shift or overtime differential layered on top, each cell tied to an effective date range set by the contract or its amendments.

That structure is exactly why it drifts quietly. A single amendment might change one cell, a rate for one labor category effective on one date, while the rest of the table stays the same. If the vendor's billing team updates its own system for some categories and not others, or applies the new date inconsistently, the resulting invoices are each individually plausible and collectively wrong in different ways.

The reference version of the rate card lives in the contract file, not in either party's billing system. Enforcement means matching invoiced line items against that reference table, not against whatever the vendor's system currently outputs, because the vendor's system is the thing being checked, not the standard it is checked against.

3. Where does three-way matching stop, and where does rate drift start?

Three-way matching checks the invoice against the purchase order and the goods receipt or approved timesheet. It confirms quantity: the hours or units billed match what was ordered and received. It does not test the price field against a contract rate schedule, because the PO usually carries a blanket rate or none at all, so a wrong rate passes the match cleanly every time.

Three-way matching is built to stop a specific kind of error: being billed for hours or units that were never ordered or never delivered. It compares three documents, the purchase order, the receipt or approved timesheet, and the invoice, for agreement on quantity and, where the PO specifies one, price.

Many staffing and services POs are issued as blanket authorizations for a dollar amount or a not-to-exceed cap, without a rate broken out by labor category on the PO line itself. In that structure, the match has nothing granular to test the rate against. The invoice can carry any rate within the cap and still pass.

Even where a PO does carry a rate, it is usually set once at PO creation and not updated when the underlying contract rate card changes mid-term. The match then confirms the invoice against an outdated PO rate rather than the current contract rate, which validates the wrong number instead of catching it.

A. What the match tests

Quantity agreement across the three documents: hours logged equal hours approved equal hours invoiced. Where a PO rate exists, the invoice price against that PO price, not against the contract.

B. What it does not test

Whether the PO rate itself still matches the current contract rate card. Whether the labor category coded on the invoice is the category the worker actually qualifies for under the contract's tier definitions.

4. How should a company check invoiced rates against the contract?

Build the rate card into a standalone reference table, separate from the PO and separate from the vendor's billing system, keyed by labor category, tier, and effective date. Match each invoice line against that table before or alongside AP processing, flagging any rate that does not match the currently effective cell for that worker's category, rather than relying on PO price fields or timesheet approval to catch it.

The first step is extracting the rate card out of the contract PDF into a structured table that AP or a controls team can actually query: one row per labor category and tier, with the rate and the date range it applies to. Contracts store this as prose or an appendix table; a control needs it as data.

The second step is comparing every invoice line to that table at the point of invoice receipt, not at contract renewal. The check is simple in principle: does the billed rate for this category, on this date, equal the rate the table specifies for that category and date. It is tedious in practice, because it has to run on every invoice, not sampled.

The third step is deciding who owns exceptions. A rate mismatch found by this check is not automatically an error; it could reflect a legitimate increase not yet loaded into the table. Someone has to confirm which side is stale before treating it as leakage.

1. Extract the rate table: Pull every labor category, tier, and effective date range out of the contract and its amendments into a structured reference, not a PDF appendix.
2. Match every invoice line: Compare the billed rate for each category and date against the reference table on every invoice, not a sample of them.
3. Route mismatches for confirmation: A mismatch could be a stale table or a vendor billing error. Confirm the direction before booking it as a finding.
4. Re-sync after every amendment: Update the reference table the same day a rate amendment is signed, before the next invoice cycle runs against it.

5. How is this different from a labor rate deviation against the MSA?

A labor rate deviation describes the outcome: the billed rate does not match the master service agreement. This page describes the mechanism that lets that outcome pass unnoticed: the approval workflow that signs off on hours has no visibility into rate, and the invoice-matching control downstream tests quantity, not the rate card, so a deviation can travel through two separate checks without either one testing the field where it lives.

It is worth being precise about the boundary here, because the two questions look similar and are not the same control problem. A deviation is a comparison of two numbers: the rate on the invoice and the rate in the contract. Finding a deviation requires knowing both numbers and comparing them, which is a data problem.

The mechanism problem addressed here is upstream of that comparison: which existing checkpoints in the AP process could have caught a wrong rate, and why neither one does. Timesheet approval was built for attendance. Three-way matching was built for quantity against a purchase order. Neither was built to hold a contract's rate schedule as its reference.

That distinction matters for where a company puts its effort. Comparing two numbers is achievable with a spreadsheet exercise done periodically. Closing the mechanism gap means adding a rate check to the workflow itself, so the comparison happens on every invoice rather than whenever someone thinks to run it.

6. What does this cost a company that never checks?

No industry-wide figure exists for how much a rate card gap costs a given company, and none should be assumed. What can be stated is the mechanism: every invoice cycle that runs without a rate-to-contract check inherits whatever rate the vendor's billing system currently applies, correct or not, and each one compounds until someone checks the table directly rather than the workflow that approved the hours.

There is no dataset behind a claim like "most companies lose X percent to this." No such figure is available here, and any number offered without a stated source should be treated as invented. What is knowable is the structure of the exposure: a wrong rate loaded once into a vendor's billing system does not correct itself. It repeats on every invoice cycle until someone compares the invoiced rate to the contract rate directly.

The exposure is proportional to how long the gap runs, not to any fixed percentage of spend. A rate that drifted last month and gets caught this month is a small correction. The same gap running for six invoice cycles across a multi-site contract labor program is a larger one, and the only way to know the size in a specific case is to run the check against that company's own contract and invoice history.

That is also why a periodic, retrospective review and a standing rate-check control answer different needs. One finds what already happened. The other stops it from compounding further.

For the wider pattern this sits inside, start with the margin drift guide. See also margin drift vs. legitimate price increases: how to tell them apart and off-contract resources: people billed outside the agreement.

7. Frequently Asked Questions (People Also Ask)

Does approving a timesheet mean the invoice rate was checked?

No. Timesheet approval confirms the hours worked and the job they were worked on. It does not compare the bill rate on the resulting invoice to the rate the contract specifies for that worker's labor category and tier. That comparison is a separate check most AP workflows do not run.

Why doesn't three-way matching catch a wrong labor rate?

Three-way matching compares the invoice, the purchase order, and the receipt or approved timesheet for agreement on quantity, and on price only where the PO carries a rate. Many staffing POs are blanket authorizations without a rate broken out by category, so there is no PO price field for the match to test the invoice against.

Where does the correct rate actually live?

In the master service agreement or statement of work and any signed amendments, not in the staffing vendor's own billing system and not on the purchase order. The vendor's billing system is the thing that needs checking, not the reference it should be checked against.

What happens when a contract rate is amended mid-term?

The contract's rate card changes as of the amendment's effective date. If the vendor's billing system is not updated the same day, invoices continue at the old rate, or at whatever rate that system defaults to, until someone reconciles the two versions directly.

Is a rate mismatch always an error?

Not automatically. A mismatch found by comparing an invoice to the reference rate table could mean the table is stale rather than the invoice being wrong. Confirming which side reflects the current, signed contract is a required step before treating a mismatch as a finding.

Can this be checked with a spreadsheet instead of software?

The comparison itself, invoiced rate against contracted rate by category and date, can be done in a spreadsheet. The harder part is running it on every invoice, every cycle, rather than as an occasional sample, and keeping the reference table current as amendments are signed.

How is this different from a duplicate payment or overbilling check?

A duplicate payment check looks for the same invoice or line paid twice. A rate card check compares one invoice line to a contract reference table for the correct price. Both are part of an AP recovery audit, but they test different fields and use different reference documents.

Does this only apply to staffing and contract labor spend?

The mechanism described here, an approval step that checks a different field than the one that actually drifts, shows up anywhere a rate card sits behind an operational approval. Contract labor is a common example because timesheet approval is a well-established, quantity-only workflow that invoices ride on top of.