Three-Way Match for Usage-Based Invoice Verification
Usage-based billing needs metered consumption data to replace goods receipts.
Three-way matching has run accounts payable departments for decades: purchase order, goods receipt, invoice, no payment without all three lining up. Usage-based billing breaks that model at its foundation, because there is no goods receipt for an API call or a unit of metered compute. This piece maps out what the three-way match becomes when consumption, not delivery, is the thing being verified, and where that verification quietly fails without the right infrastructure behind it.
The classic version is simple to state. A purchase order records intent: what was ordered, at what price, from whom. A goods receipt note records delivery: what actually showed up on the loading dock, confirmed independently by the buyer's own warehouse staff. The vendor invoice records the payment request. When a company matches all three, it knows it's paying for something it asked for and actually received. Dropping the goods receipt note collapses the process into a two-way match: PO against invoice, intent against request, with nothing in between confirming that delivery happened. For SaaS subscriptions billed at a flat monthly rate, or retainer arrangements with no discrete delivery event, two-way match is fine. The product is access rather than a shipment, so checking a "receipt" carries little meaning.
Usage-based billing sits in a different category. Consumption is the delivery event, metered continuously rather than confirmed once, and it needs its own verification leg. That leg doesn't exist in most accounts payable workflows today, which is the gap this piece is about.
What the three legs of a usage-based match are
The framework keeps its three-leg structure. What changes is what fills each slot.
The purchase order becomes something looser and, frankly, harder to pin down, spanning a signed contract, a rate card, committed spend tiers, and whatever overage terms got negotiated. The complication is that rate cards move. Among the top 500 SaaS and AI companies with transparent pricing, there were more than 1,800 pricing changes in 2025 alone. A match process that checks an invoice against today's rate card, rather than the rate card in effect during the actual billing period, will pass invoices that are wrong and fail invoices that are correct. Hybrid pricing compounds the problem further: a single invoice might carry a subscription base fee, usage overages, and credit drawdowns in the same line-item list, and each of those three components ties back to a different clause in the contract.
The goods receipt note becomes metered consumption data, and this is the substitution that does all the real work. It has to be the aggregated, deduplicated, auditable record of what a customer consumed during the billing period, and it has to come from a system the buyer controls or can independently audit, not simply the vendor's word for it. The unit varies by product: API calls, tokens, GPU-minutes, voice minutes, resolved interactions, data processed. Whatever the contract's billing dimension is, that is the unit the receipt needs to speak in. And unlike a warehouse receipt, which gets stamped at one moment when a truck arrives, this one accumulates continuously across the entire billing period.
The invoice itself doesn't change in form. Line items, amounts, payment terms, the same document it's always been. What changes is scale: a single usage invoice can contain thousands of rated line items derived from millions of raw underlying events. Checking that by hand isn't really an option anymore.
The hardest leg to produce reliably: the metering layer
Physical goods receiving has a built-in independence that usage billing lacks. A warehouse team produces the goods receipt note at the moment of delivery, and that team has no stake in the vendor's invoice being right or wrong. Usage billing rarely has an equivalent. Most buyers accept the vendor's own reported consumption figures with no independent metering of their own. This means the "three-way match" they're running is actually a one-way check: does the invoice match the vendor's own claim about the invoice? Most buyers accept the vendor's own reported consumption figures with no independent metering of their own, so the "three-way match" they're running is really a one-way check that isn't a control. That's an acknowledgment.
Building a metering layer that can stand in for an independent goods receipt means solving several distinct problems, and each one is a control point on its own, not just an engineering task.
Ingestion has to capture every usage event, attribute it to the right customer and billing period, and store it durably at scale. Deduplication has to catch the duplicate events that retries and outages generate, because without it a buyer's usage total is artificially inflated and the match either fails outright or, worse, passes an invoice it shouldn't. Aggregation has to roll raw events up into the quantities the pricing model bills against, at the right granularity: per-minute, per-hour, or per-day. Mid-cycle changes, upgrades, downgrades, cancellations partway through a period, all need to produce prorated charges that trace cleanly back to the event that triggered the change. And an audit log needs to preserve timestamped records of everything, so that any single line item on an invoice can be walked back to the raw events that produced it.
Skipping any one of those still lets the pipeline work fine, right up until it doesn't. A naive metering setup can run cleanly for months and then fall apart the moment an AI agent starts generating a very large volume of events in a short window. Enforcement logic reads stale state, a customer blows past their limit, and the metering layer only catches up to reality after the overage has already been billed. That is not a hypothetical.
In July 2025, a developer generated a single-day invoice of $7,225 after usage triggered a large overage, an incident that became public when a post documenting it on X reportedly drew 797,000 views within a week. Nothing in that sequence involved an independent check of consumption against the contract commitment before the charge went out. The receipt, in effect, was never verified. It was simply issued.
The fast-path / slow-path architecture and what the match can verify
Metering infrastructure built to withstand this kind of scrutiny generally runs two separate paths, and the distinction between them matters enormously for what a three-way match is actually allowed to trust.
The fast path produces approximate, real-time aggregations, the numbers that show up on customer dashboards and that enforce spend caps in-flight. It runs at sub-second latency because its entire job is to catch a runaway customer before the bill balloons, not to produce a number precise to the last event. The slow path is different: it computes exact aggregations after the billing period has fully closed, and that exact figure, not the fast-path estimate, is the number that belongs on the invoice.
For a three-way match, this distinction isn't a technical footnote, it's the whole ballgame. The slow-path total is the metered receipt, the direct equivalent of the goods receipt note, and it's the only figure that should ever be matched against the vendor's invoice. Matching against a fast-path approximation is the equivalent of signing off on a shipment using a preliminary dock count that nobody ever reconciled against the actual warehouse inventory system. It might be close. It might be close, but it's not verification.
Complex pricing models add another wrinkle: multiple aggregation windows, minute-level, hour-level, day-level, can each generate a different potential billable quantity from the same underlying events. This is how billing structures like "highest peak usage in the period" or "daily active unique users" get computed. The contract has to specify which window governs, because without that specification, two parties running the same raw data through different windows will land on two different, both defensible, numbers.
None of this works if the ingestion pipeline itself goes down. Events that were never captured cannot be reconstructed after the fact, no matter how good the aggregation logic is downstream. Billing-grade metering infrastructure is generally held to a recovery point objective of zero events lost, a materially stricter bar than most observability or logging pipelines are built to meet, and for good reason: an observability gap costs you a debugging session, a metering gap costs you a disputed invoice.
The matching workflow in practice
Running this match in practice breaks into four steps, and the order matters because each step depends on the one before it.
Before the billing period even opens, confirm the applicable contract and rate card version, the one in effect for that specific period, not whatever is currently live in the vendor's system. Record the committed spend tiers, overage rates, any credit balances, and negotiated caps that apply, and flag in advance any invoice that will mix a subscription base fee with usage charges, since each of those components checks against a different contract term.
At period close, pull the slow-path metered consumption total from the buyer's own system, or from a vendor export that can genuinely be audited independently rather than just taken on faith. Confirm the unit of measure lines up with the contract's billing dimension, tokens against tokens, GPU-minutes against GPU-minutes, and confirm the time range matches the invoice period exactly, including any mid-cycle adjustments.
When the invoice arrives, extract the line items. This step alone is where usage invoices diverge sharply from goods invoices in terms of difficulty: with potentially thousands of rated lines behind a single bill, manual extraction is no longer realistic at any real scale, so capture supported by an automated model becomes less a convenience than a requirement. Identify each component separately, base fee, tiered usage charges, overages, credit drawdowns, taxes.
Then run the actual match. Compare the metered consumption total against what the vendor claims was consumed. Apply the contracted rate card independently to the metered total and compare that calculated amount to what was actually invoiced. Check whether consumption crossed a pricing tier boundary mid-period, and if it did, verify the vendor split the charge correctly across both tiers rather than applying one rate to the whole period. Check that any credit drawdown matches the metered consumption at the contracted conversion rate. Each of these checks depends on the metered total from the earlier step being right. The metering layer, not the invoice, is the leg the entire process actually rests on.
Where controls break down without purpose-built metering infrastructure
The most common failure is having no independent metering. A buyer without a real Leg 2 is matching invoice against contract only, a two-way match no matter what the process is labeled internally. Phantom charges, double-counted events, pipeline lag that lets an overage slip through unnoticed, none of it is detectable, because there's no independent figure to catch it against. Structurally, this matches paying a goods invoice with no goods receipt on file, the exact gap three-way matching was invented to close.
A second failure occurs even at companies that do collect their own usage data: their internal figures don't reconcile with the invoice. Internal logs might count API calls while the vendor bills by tokens. Internal systems might track by calendar day while the vendor's billing period runs on a different cycle. This is especially common at companies running several fragmented internal billing codepaths that were never built to agree with each other. Engineers, rather than accounts payable, run a manual reconciliation process that often eats the first week of every month.
A third failure comes from rate card versioning. If a buyer's system only stores the current rate rather than the rate that was actually in effect at the moment of consumption, there's no way to independently check whether a vendor applied the right price to usage that happened before a price change went into effect. With more than 1,800 pricing changes recorded across the top 500 B2B SaaS and AI companies in 2025 alone, this isn't a rare edge case, it's a routine occurrence that any serious match process has to account for by default.
The fourth failure is deduplication, or the absence of it. Events that get emitted twice during a retry or an outage get counted twice in a buyer's own metering total, which inflates that total above what actually happened. That's arguably the most dangerous version of this failure, because it doesn't cause the match to fail, it causes the match to falsely succeed, validating an invoice that's actually overstated. The standard fix is idempotency keys attached to every event at ingestion, so duplicates get caught and dropped before they ever reach the aggregation layer. Without that fix in place, a company can run what looks like a rigorous three-way match every month and still be paying for consumption that never happened.
